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

[Akash Rawal]

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.
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?

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

Regards,
Akash Rawal