On Monday 10 October 2005 00:13, Oswald Buddenhagen wrote:
> On Sun, Oct 09, 2005 at 11:34:42PM +0200, Martijn Klingens wrote:
> > Come to think of it, that might not work. The code needs to do some
> > translation, e.g. in the case of cr/lf and extracting out-of-band data to
> > e.g. signal problems that an intermediate hop detects. Hence, data cannot
> > be passed in a zero-copy fashion and always needs processing in all steps
> > in the chain.
>
> i think simon meant that the objects representing the different "hop
> stages" are not really processes (in the OS sense), they are in-process
> filters. only the most nested filter talks to a "real" (local)
> process.

True. In fact, technically it doesn't even have to. The only reason I use the 
ssh and su executables is because I don't feel like reinventing wheels, but 
if one wants to write, say, a telnet implementation using KDE's socket 
classes, why not?

> to me it sounded like simon outright refused the idea of a generic
> redirection api. i'll bother qt-bugs; let's see what the "official"
> tt channel says. if they refuse, qprocess as a base class falls flat;
> afaics, it is impossible to extend it without reimplementing it
> completely (including the process manager, as it is private).
> other than that, kprocess will definitely come closer to qprocess, as
> some of the mess from the old api must be removed in any case. the rest
> is naming ... oh, well - and the qiodevice inheritance.

Ok. Since it'll probably take a while until I can work on it anyway I can wait 
for some weeks for the reply. If there's anything interesting or 
revolutionary, please do inform me. Also I would like to receive a heads-up 
when you think the K4Process API starts stabilizing, so I can adjust 
KExtProcess accordingly.

-- 
Martijn