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
