KProcess overhaul

[Martijn Klingens]

On Monday 03 October 2005 20:51, Oswald Buddenhagen wrote:
> On Sun, Oct 02, 2005 at 07:29:35PM +0200, Simon Hausmann wrote:
> > [...] But the point about QIODevice was that it appears that the
> > QIODevice interface may be rich enough to create such chains of
> > objects, if for example each of these classes inherits from QIODevice,
> > had a reference to the next (QIO-)device, would connect to its signals
> > like readyRead and read and write data from/to it.
>
> you must be kidding ... you just suggested using the supervising program
> (our qt/kde app) as a proxy for potentially gigabytes of data (imagine a
> pipe from mkisofs to cdrecord, like in k3b).

Ehm, no, you misunderstood what KExtProcess does and what it is exactly 
chaining. It's not meant to create virtual pipes between different 
KExtProcesses.

The idea of chaining is that you can reach distant hosts. For example ssh to a 
gateway server. From there ssh to another server. There su to root. Then 
execute the required command (say, tail -f /var/log/messages).

KExtProcess first gets the output from the first ssh command. It parses it, 
asks for credentials if needed and feeds them to ssh. Once the ssh client has 
set up a shell on the gateway server it sends shell commands over the ssh 
connection to launch the ssh to the other server.

From there on the original SSHProcess shifts to pass-through mode and only 
intervenes if the connection somehow breaks or other problems arise. 
stdin/out/err from that point on are sent to the chained process, the second 
SSHProcess. This object repeats the login process for the other server and 
sends shell commands to launch su.

Next, the SuProcess gets control, passes the su credentials and launches the 
real process (tail -f). Only then the KDE application gets any data from the 
receivedStdout/err signals, namely the data from the shell command.

The only use case that I can imagine where gigabytes of data can be proxied is 
kio-fish, which is not very different from the way that one works now, and 
which cannot really be avoided. Under normal conditions there's not that much 
data going over the channel at all.

-- 
Martijn