KProcess overhaul

[Oswald Buddenhagen]

On Sun, Oct 09, 2005 at 11:34:42PM +0200, Martijn Klingens wrote:
> > The part where KProcess or QProcess come into play is at one end of the
> > chain, where an object needs to sit that fires up a local process (ssh
> > client, etc.).
> 
> 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.

> So, Ossi, what will you do for KDE 4? Take QProcess' API as basis for 
> K4Process? Or continue the KDE 3 way of doing things? Your last mail in the 
> thread only said "so i'm going to design kprocess2 now [...]", but confused 
> me as far as explaining whether it'll be based on K3Process' or Q4Process' 
> API.
> 
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.

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
--
Chaos, panic, and disorder - my work here is done.