Re: [evolution-patches] Camel-stream-process.

[Not Zed <notzed ximian com>]

On Wed, 2003-09-03 at 13:23, David Woodhouse wrote:
> On Wed, 2003-09-03 at 12:39 -0500, Not Zed wrote:
> > Hmm, I had a slightly different approach in mind to solve this
> > particular problem.
> > 
> > Instead, have a CamelProcess or something class, that handles all the
> > setup/forking/failing, etc.  And then you can attach streams/or get raw
> > fd's on any specific fd's on the other end.  e.g. so you can better
> > handle the case of a missing command, or error output, or even other fd
> > output (e.g. for gpg execution).
> > 
> > Not sure on the api exactly though (i had some good ideas but forgot
> > them)
> > 
> > Something like, perhaps, although i'm not entirely convinced ...
>  <...>
> > But ... since i can't think very straight today ...
> 
> I'm wary of overdesigning it.

Not much use underdesigning it.

> > Having said all that, the attached could be used temporarily (put it in
> > the imap provider dir perhaps?).
> 
> That way lies duplication. If we put it in camel/ then the next person
> who wants to use it can either do so as-is or modify it accordingly. 

Well as it is now, it isn't useful for anything else that needs
processes.  e.g. piping to a shell command, filtering through a shell
command, or running a subservient task like gpg.  Which is why i suggest
you just leave it in imap.

> > Does it properly handle the case where the command doesn't exist, etc?
> 
> Yes, it reports connection failure.