[Evolution-hackers] Re: [evolution-patches] Connection to IMAP server via piped subcommand, PREAUTH support.

[David Woodhouse <dwmw2 infradead org>]

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