Fwd: NXFish: How to integrate with KDE?

[Martijn Klingens]

Kurt Pfeifle said:
> - - Too small changes to be worth forked and maintained separately. (The
> FISH-Server can be maintained seperately)
>
> - - Too specific needs (access to some port where a FISH-Server is
> running) to
> be integrated into the FISH module (?)
>
> - - Real Access to FISH-Server is done via nxfish-client instead of ssh,
> which
> at the moment is just a netcat to some port.
>
> Does anyone have any idea how one could integrate this nice and cleanly
> into KDE?

I have an idea, but it's still about 50% vapourware at this point in time,
and that'd be integration into the extended KProcess library that I'm
developing in kdeplayground/sysadmin/kextprocess.

--- [ KExtProcess ] ---
KExtProcess, in short, is a KProcess-like API that's mostly
source-compatible with its cousin, but is more modular and can run
remotely. E.g. if you want to run an application on a server you use
KExtProcess to create an SSHProcess and you can run the app there without
having to explicitly add SSH support to your app -- use LocalProcess and
the process runs locally, or SuProcess and it runs as another user, it's
all wrapped in the library. Even cooler is the ability to chain processes,
e.g. to ssh to a server, then su to root and THEN start the app. Or to
chain multiple SSH calls together to reach distant hosts.
--- [ / KExtProcess ] ---

Possible uses for KExtProcess are of course administration tools and
developer tools (remote compiling or debugging for instance), but also ...
kio-fish. Ideally kio-fish should support KExtProcess profiles in the
future and thus allow file system operations on any system reachable
through KExtProcess, regardless of whether it's a LocalProcess,
SSHProcess, TelnetProcess or NXProcess.

Now, back to the present: as a proof of concept the extprocess library
works for a couple of months, but I need time to polish the library and
the API and to complete it for actual usage in applications. Also, someone
who knows kio-fish intimately would need to port it to KProcess with PTY
support (useful anyway to reduce code duplication and have all PTY
handling in one place). Once kio-fish uses KProcess the porting to
KExtProcess is straightforward and easy to do later on.

I hope to be able to finish KEP before KDE 4, but even though that gives
me quite some time for what is essentially not too much work anymore I am
afraid I cannot make a 'hard' promise. Reality taught me that I cannot
always spend enough time on KDE to do serious coding, and I am also
involved in kde-pim.

So, summarizing, one the one hand I'd really like to point you to KEP, but
on the other hand it's only about halfway finished, with most work left on
the API and usability side and not so much the technical part. Whether you
want to put your bets on unfinished technology is up to you of course :)

-- 
Martijn