> > Because of their unreliability, I think using signals to
> > modify wget's behaviour and configuration on the fly is a
> > very bad idea.
>
> In what way are signals unreliable? Using interrupt signals to > halt whatever a program is doing, and bring up a command prompt > is not exactly unusual (though typically, whatever the program > was doing previously is abandoned).

ah ok, i see. you're talking about switching wget's operating mode upon receival of user-generated SIGINT. that could work, in my opinion.

i thought you guys were planning to add complex forms of coordinations with other non-interactive external programs via unix signals, e.g., SIGUSR1 stops downloading process, SIGUSR2 resumes  downloading process, SIGINT skips the current download and starts the next download, etc. this sounds like a nightmare to me.

BTW, unix signals are unreliable in the sense that they don't get queued. as a result, SIGX can be generated N > 1 times and delivered just once.

> > I think we should consider a dynamic language for plugins.
> > Ruby would be my first choice, but Python is an excellent
> > alternative.
>
> I see no reason why it couldn't be both, plus Perl and whatever
> else. We just provide the API, and the rest is just glue.

right.

> I'm not sure how plugins would help with dynamic, interactive
> reconfiguration, though.

of course, wget should be changed to support dynamic reconfiguration. but on top of that, we could add plugin support to make dynamic reconfiguration easily exploitable from external, higher level code.

> > As Micah says, having interactive console would also be
> > great. Maybe that could be implemented with a plugin as well.
>
> Actually, that was Tony's idea :)

sorry, guys. i skimmed through your emails in a hurry, and i totally misunderstood what tony was suggesting.

my proposal to implement interactive console via hooks and plugins is still valid, though.

Because of their unreliability, I think using signals to modify wget's behaviour and configuration on the fly is a very bad idea.

Instead, I believe we can obtain the same result by introducing support for plugins and have wget call external code from well-defined places. For instance, we could define pre-download and post-download hooks, and let plugins interact w/ wget by appending new urls to the download queue or cancelling the download of urls.

I think we should consider a dynamic language for plugins. Ruby would be my first choice, but Python is an excellent alternative.

Notice that this would allow us to easily write new parsers to extract urls from currently unsupported mime types, e.g., css or javascript.

As Micah says, having interactive console would also be great. Maybe that could be implemented with a plugin as well.

If you mean that an interrupt signal should send it to an interactive mode, that could work, but I think "batch mode" should be the default; that is, you should specifically give an option to enable interactive mode on interrupt (as, according to descriptions that exist in various places, wget is a "non-interactive" utility, and I'm not convinced it should become an interactive one, at least in default invocations).

Another idea would be to have a separate program that communicates with the first, by means of a pipe, to provide equivalent functionality; but perhaps this would complicate these things overly much.

Still, it'd be a heluva lot of work, and I'm not sure I'd be interested in doing it, myself. If it's something you'd like to work on, Tony... :)

However, I'd prefer to reserve this bug for the original proposition; let's submit a new bug for the interactive features.

I have long wished that wget had an intelligent interrupt signal handler (perhaps disabled by a command option for batch jobs and such). Some options it could offer:

• help: explain all these options :-)
• continue: resume the job
• skip: stop downloading the current file and continue the job
• next: finish downloading the current/next file and return to the interrupt prompt
• abort: stop the job and leave downloaded files unchanged (current behavior)
• exit: stop the job, but convert the files downloaded so far
• suspend: save the job state in a file for later resumption
• status: report on what's left to be done
• options: allow the user to enter (some) command-line options to change the ongoing behavior of the job

For the "options" case, some command-line options clearly make no sense to change once the job is running.

I'm wondering if wget should attempt to convert the files it has downloaded, after encountering an interrupt signal. A second interrupt could cause it to exit immediately.