KProcess overhaul

[Oswald Buddenhagen]

On Sat, Apr 15, 2006 at 10:50:14AM +0200, Ralf Habacker wrote:
> for windows the recent KProcess implementation is unusable, so I'm going 
> to provide an initial KProcess implementation with the following steps:
> 
feel free to do so, but be prepared that qt 4.2 will make at least some
of your work be in vain, and you will be told by some kde code dev
employed by tt "why maintain code in kde if we can offload it to tt?".
of course it is just a minor detail that i'm waiting for solid 4 months
to get even a *remote* specification of what is planned.

>   5. The results of the studies are
>         2. QProcess will probably be able to deal with KDE specific
>            forking and pty needs because there is are protected hooks:
>               1. setupChildProcess -  This function is called in the
>               child process context just before the program is
>               executed on Unix or Mac OS X (i.e., after \e fork(), but
>               before \e execve()). Reimplement this function to do
>               last minute initialization of the child process.  but
>               this have to be confirmed by some unix gurus.
>
that's too little. i mean, we *could* build it on top of it, but it
would be utterly ugly.

>         3. io redirection will be able because qProcess returns the
>            data in memory, which could then be redirected to anywhere
>
that's an argumentation i heard from tt as well. to make it absolutely
clear: using the parent process (that is, the QProcess) as a proxy is
*no option*:
- resource usage (double copy)
- dependency of a forked pipe (multiple connected child processes) on
  the parent:
  - latency, up to reliability problems
  - no way to exit the parent and let the children live on

>   7. My plans are
>         2. To implement required functions/features in an iterating way
>            to avoid to much headage about thinking what may be required
>            and what not to early.
> 
that way you easily end up with a mess. you should at least have an idea
of the Big Picture.

> Things to discuss by the KProcess gurus:
>    1. Should KProcess include QProcess public, protected or in 
> KProcessPrivate ?
>
public is fine, i guess.

>    2. Who will implement the unix and mac related parts ?
>
me for unix, but not before tt makes up and reveals its plans.

>    3. Who will write the doc ? (I'm currently not very familar with KDE 
> doc writing, I can write examples as shown  below)
> 
doc? hääää?!? are you stoned?!??!? :)))

> now it is real requred to fix this stuff, because the next major
> windows KDE issue - kdeinit and kioslave loading are waiting for a
> solution.
> 
yeah - tell tt.

to sum it up, i think you can do the following without potentially
wasting work:
- move kprocess/kprocio to kde3support
- create class KProcess : public QProcess and implement everything you
  need that can be *cleanly* implemented on top of existing
  functionality - i think it is reasonable to assume that our api will
  be qprocess-like, even if we find ourselves forced to reimplement it
  from scratch. not that i like every detail of that api, but i guess it
  makes sense for the sake of consistency - at least as long as our
  extensions can be done without them looking bolted on.

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