Tue 17 Jul 2007 10:10:54 PM UTC, comment #8:
> > 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.
|