KProcess overhaul

[Martijn Klingens]

On Sunday 02 October 2005 19:29, Simon Hausmann wrote:
> On Thursday 29 September 2005 20:36, Oswald Buddenhagen wrote:
> > On Tue, Sep 27, 2005 at 11:23:54PM +0200, Martijn Klingens wrote:
> > > On Monday 26 September 2005 20:13, Oswald Buddenhagen wrote:
> > > > enum Direction { DefaultForFD, ReadOnly, WriteOnly, ReadWrite };
> > > > enum StdFDs { StdInFD = 0, StdOutFD = 1, StdErrFD = 2 };
> > >
> > > "DefaultForFD" doesn't really sound all that explanatory, although when
> > > seen in the context of the API that uses it it passes the test --
> > > barely.
> > >
> > > Furthermore this is the era of code completion,
> >
> > yeah - and 160 column views. ;)
> > oh, and people can read faster meanwhile. ;)))
> >
> > > > // piping processes is slightly more tricky. first variant:
> > > > KProcess::redirect( int handle, KProcess *drain, int drainHandle,
> > > > bool bidirectional = false );
> > > > // however, the definition that this-> is the source is quite
> > > > arbitrary. // also, it is not clear how to control the pipe as a
> > > > whole.
> > >
> > > (And the rest of the piping)
> > >
> > > From what I understood from Simon at aKademy QProcess got a major
> > > overhaul and is now a QIODevice
> >
> > yes
> >
> > > that supports chaining.
> >
> > huh? which methods indicate such capability (whatever it might mean in
> > that context ...)?
>
> No methods indicate that :)
>
> If I understand Martijn correctly with regards to process chaining then he
> for example wants to have a class that is capable of handling simple ssh or
> telnet authentication by looking for some magic tokens in the input,
> handles the authentication and afterwards just pipes input through to
> output.

Mostly correct. See my other mail I just sent for the minor differences that 
apparently confused Ossi :)

> In fact I think he already has that code.

Yes, the single-hop case works since I imported the code in CVS, and the 
chaining across multiple hops also already worked before the migration to 
Subversion

> 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 don't see it as a problem, since there's relatively little data to be 
processed and chains will not be much deeper than 3 or 4 steps in most cases 
for sysadmins and not more than 1 or 2 steps for home and power users, so the 
overhead should not be disturbingly high.

What's much more important for me is to have an API (APIs?) that look as close 
as possible to the 'normal' KProcess/QProcess that is going to be the 
mainstream workhorse in KDE 4.

So if KDE 4 will prefer a KProcess that's vastly different and has a 
QProcess-like API (with KProcess as we know it moving to K3Process) I'll need 
to adapt KExtProcess to look and behave similar.

If KDE 4 will have a KProcess that is almost like what we have now I can keep 
the code as as, apart from perhaps adding createQExtProcess() methods to the 
factory that create a proxy object that behaves like QProcess for those who 
prefer that.

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.

-- 
Martijn