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

[Not Zed <notzed ximian com>]

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 ...

typedef int (*CamelProcessSetupFunc)(CamelProcess *, void *data);

CamelProcess {
	char *command;
	GSList *environment;
	int childpid;

	// just creates object
	CamelProcess *new(const char *command);

	// add an environment var for child
	void add_env(const char *env);

	// add a pipe (or socket?), id is for the app to find it later
	int add_pipe(int id);

	// get the pipe fd by id, if parent == true get parent end
	int get_pipe(int id, bool parent);

	// fork, run setup(cp, setup_data), then exec command
	// synchronously return error code if there is one
	int run(setup, setup_data);
}

Could even have CamelProcess with no command/env knowledge (i.e. it
doesn't exec), and CamelCommandProcess subclass which adds that.

But ... since i can't think very straight today ...

Having said all that, the attached could be used temporarily (put it in
the imap provider dir perhaps?).  Does it properly handle the case where
the command doesn't exist, etc?


On Wed, 2003-09-03 at 10:34, David Woodhouse wrote:
> Camel stream implementation for running commands. I'll update the IMAP
> and preauth stuff shortly but this is simple...
> 
>