On Mon, 2003-02-24 at 10:38, Not Zed wrote: > Wow, cool. > > If you dont mind, i wouldn't mind the camel-stream-subcommand thing to > work a little differently. This way we can re-use it in a few other > places we need to use pipes by making it slightly more generic.
OK, cool. Mail redirected to evolution-hackers@ which is presumably a better place to discuss it. The original mail to evolution-patches, if anyone wants to reference it, is at ftp://ftp.uk.linux.org/pub/people/dwmw2/evo/evo-subcommand Apologies for the large quotation -- since the original mail wasn't copied to the list, I figured I should keep it... > Idea i had was to have a camel-async-process object. This object > handles all of the fork()'ing, signal handling, and mapping arbitrary > child fd's to camel-stream-fs's which already handles reading/writing. > Although it might need a simple subclass of stream-fs so that it can > handle multiple read/write pipes without causing deadlocks with child > processes. > > api perhaps something like > > CamelAsyncProcess { > enum PipeTpe { > PIPE_READ, > PIPE_WRITE > }; > > /* fdno is the child's fd */ > CamelStream *add_pipe(PipeType type, int fdno); > /* redirect a child's fd to /dev/null */ > void add_ignore(PipeType type, int fdno); > /* exec the command in /bin/sh in a fork'd process */ > int run_shell(char *command); > /* exec a command */ > int run_exec(char * > /* send the child a signal */ > int kill(int signal); > > /* Events (signals) ... */ > void child_quit(int retcode); > } > > This would make filtering messages through spamassasin and the like > trivial to do, and reduce a bunch of code duplication in similar cases. > But it would be a bit of work to make it work in all cases. This of > course could be added later anyway, it just might be a good opportunity > to get it done at the same time. You have to set up all the file descriptors _before_ the child is kicked off, of course. And you possibly want to be able to pass in an _existing_ file descriptor (or filename, but fd is more flexible and race-free) for it to use. To avoid pipe-related deadlock you'd want to buffer the pipe(s) coming back from the child and ensure you poll them on every send, if not more often. No chance of getting SIGIO I suppose? :) You probably want to handle environment variables too -- I thought about the imap command taking params like '%h' and '%p' for host, port, etc. but figured environment variables were probably better. It might be worth looking at the KProcess object for inspiration -- that's a fairly similar thing. Or OProcess (from Opie) which is a slightly less heavy-weight version of it. Going off at a tangent, we probably also want to be able to run SSL over these too. What chance of making the TLS code wrappable on an existing CamelStream? There's a lot of work here to do this properly -- I'm far more inclined to start delving into IMAP code, to be honest. And once it's _done_ I think we may want to keep the subcommand-stream as a _simple_ wrapper around it anyway, so perhaps we should commit that with a view to improving it later? > The config stuff, you might be able to do via entries to the head of the > conf table in imap/camel-imap-provider.c, although it depends a little > on if the options required are part of the code in mail/*. OK, I'll play with it. Ideally, I'd like to hide the SSL options if a command is specified -- or maybe change the SSL options to 'connection method' and have the choices be 'command/unencrypted/SSL/TLS' (probably replacing 'SSL' and 'TLS' with something more pleb-friendly like 'Always-encrypted' and 'Negotiate encryption after connecting' or something). That does require real changes to the account config code, though. Would you be happy with that? -- dwmw2 _______________________________________________ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
