Re: [Bug-wget] [GSoC] Proposal: “Design and implementation of a framework for plugins.”

[Tim Rühsen]

On 04/03/2017 03:50 PM, Akash Rawal wrote:
> On 04/03/2017 04:20 PM, Tim Rühsen wrote:
>> I like this. We can have this without changing much of Wget2's option
>> processing code. Add --plugin to Wget2 (we will have a list/array of
>> plugin names than).
>> Define a option name scheme to identify options for a certain plugin,
>> e.g. --plugin-foo-<option-name>=value. Make as as simple as possible,
>> e.g. a value is mandatory (bool is 1|0 or y|n or whatever).
>>
>> When the current option processing doesn't find an option in it's list,
>> we special check for --plugin-<plugin-name>-<option-name> and give the
>> key/value pair <option-name>/<value> to a function that is provided by
>> the plugin (e.g. wget_plugin_set_option(const char *option_name, const
>> char *value).
>>
>> With this you can provide CLI options to plugins without changing much
>> in Wget2's code.
>>
>> Regards, Tim
>>
> This could be done with the following:
>   -  Add condition to set_long_option() in option.c checking if
>      _option_ begins with --plugin- (4-5 lines), if yes strip
>      the leading "plugin-" and call another function, say
>      set_plugin_option(option, value)
>   -  set_plugin_option() will look up maximum length matching
>      "<plugin-name>-" using a variant of binary search.
>   -  If the plugin discovered has opted in to receive options,
>      strip "<plugin-name>-" _option_ and pass  the remaining
>      option and value to plugin-registered function.

If the plugin exposes the function 'set_plugin_option', then it opted in
to receive options. How the plugin deals with the options doesn't matter
- we treat it as a black box that return ok/error (and
possibly/optionally an error message for display/log).

> To implement this all we need to maintain is a sorted list
> of plugins. No extra memory allocations will be needed for
> option processing.
> 
> I could still change proposal before 16:00 GMT. So what do you people
> think?

If you feel like it, add it. But don't go too deep into implementation
details - these will/might change later anyways. The today's proposal is
mainly to have a base to judge the students on. As far as I understood,
students and mentors will work on further polishing the implementation
details. These are not set into stone. Same goes to the time schedule.

> (Also a friendly reminder to everyone that final proposals can be
> reuploaded till 16:00 GMT, so don't wait till last moment. )

Regards, Tim

signature.asc
Description: OpenPGP digital signature