[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-wget] GSoC Project | Design and Implementation of a Framework f
From: |
Tim Ruehsen |
Subject: |
Re: [Bug-wget] GSoC Project | Design and Implementation of a Framework for Plugins |
Date: |
Mon, 20 Mar 2017 16:15:44 +0100 |
User-agent: |
KMail/5.2.3 (Linux/4.9.0-2-amd64; KDE/5.28.0; x86_64; ; ) |
On Monday, March 20, 2017 3:06:51 AM CET Didik Setiawan wrote:
> Hi everyone!
>
> I am Didik Setiawan. I am studying Computer Science and Engineering at
> Surakarta University, Indonesia. I am interested in participating in Google
> Summer of Code of this year (2017) under GNU organization, especially
> Wget2.
>
> I am interested in a project related to design and implementation of a
> framework for plugins of Wget2.
>
> For now, what I understood about this case is that I need to make Wget2
> load libraries at times other than during the startup of program. This could
> be done by include the header file <dlfcn.h> to use an API for opening a
> library (dlopen()), looking up symbols (dlsym()), handling errors
> (dlerror()), and closing the library (dlclose()). Then after I modified the
> main Wget2 program, I could create some plugins (dot so files) to run
> custom operation.
>
> What are your suggestions about these project? Please correct me if I lead
> to misunderstanding.
Welcome, Didik !
One way to implement plugins is via libdl (dlopen(), ...), and that is what I
have in mind. That is not perfectly portable, but our first goal will be
systems that support dlopen().
Since we can't (or want) to make everything pluggable, we should first address
the already requested functionality. There should be (some ?) requests in the
wget1.x issue tracker that ask for plugin / external program for some good
reasons. You should review these, pick the parts that seems reasonable to you
and implement these first.
E.g. I remember someone asking for some customisable 'filter' for URLs to
follow. In terms of a loadable module, that would be a function that takes a
URL and returns 1|0 (yes|no). Or a bit more general: takes a URL plus extra
information, e.g. referer, host, mimetype, ... and maybe returns a list of
URLs to fetch. Whatever makes sense.
One goal would be to make up data structures and an API that can be extended
without breaking compatibility between wget2 and the plugin in the future.
E.g. a newer wget2 should still be able to work with an older plugin and vice
versa.
Just make up a sketch of your ideas and we (you and one of our mentors) will
improve/discuss that.
Regards, Tim
signature.asc
Description: This is a digitally signed message part.