[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-wget] [GSoC] Proposal: “Design and implementation of a framewo
From: |
Tim Rühsen |
Subject: |
Re: [Bug-wget] [GSoC] Proposal: “Design and implementation of a framework for plugins.” |
Date: |
Mon, 3 Apr 2017 16:10:47 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 |
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