klingens at kde.org
Sun Oct 9 22:19:57 BST 2005
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
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.
More information about the kde-core-devel