bug-wget
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug-wget] [GSoC] Proposal: “Design and implementation of a framework fo


From: Akash Rawal
Subject: [Bug-wget] [GSoC] Proposal: “Design and implementation of a framework for plugins.”
Date: Fri, 31 Mar 2017 20:52:42 +0530
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0

Hello,

First of all, thanks for the initial review of my proposal!

I have made some changes in response to the comments as well as last
mail on the mailing list by Darshit Shah. Kindly consider reviewing it.
For reference here is the link.
https://docs.google.com/document/d/1SBM-jNG5dJL85C7iK9aid2eDlByrxOsYUNDrk4049vQ/edit?usp=sharing

The proposal is still not final, in the sense that I am analysing the
code for further ideas of what can be customized using plugins.

I was asked to elaborate on rewriting of command line option processing
code. So here are my thoughts on it.

The current code in src/options.c has following drawbacks:
  -  Built around order-insensitive and idempotent model (Supplying
     an option modifies a variable). This might be adequete for wget,
     but might not be the case for plugins. Repeated options or
     order of options can matter for plugins.
  -  The need for keeping the list of options sorted. I don't think
     we can expect plugin writers to do the same.
  -  And most importantly, options cannot be added at runtime.

So far I think rewriting the option processing code would be easier
than trying to patch existing code to support custom options.
Some parts of the original code could be reused but structure
would undergo a drastic change anyway.

The idea I have is to expose an interface for plugins to describe
command line options they want to receive. I have attached a
prototype header. From this interface, wget will have a list of
command line options to support, along with plugin function to
be called for handling plugin specific options. In addition to
using this to parse command line, wget can Use the descriptions
and category information provided to generate --help output.

Regarding the need to support plugin side addition of command line
options at the first place, here are my thoughts.
Plugins might need additional data from the user. I can think
of 3 ways in which it can be done:
  1. Environment variables.
  2. Files with well-known names.
  3. Command line.
Environment variables have a disadvantage that they are automatically
passed to the subprocesses, creating a chance for interference.
Also, name clashes cannot be discovered.

Using files with well-known names has a chance of interference
with parallel running instances of wget.

None of these disadvantages are shared with using command line
options.

Opinions are welcome.

Regards,
Akash Rawal.



Attachment: wget_argp.h
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]