I just committed a KDE 4 port of the SLP kioslave into playground. The KDE 3 version might be at least known to the OpenSuse users, as Novell is a strong supporter of the Service Location Protocol (SLP, srvloc), and so it had been developed in some Suse repository and always been installed with the OpenSuses.
Why did I do this port? I am looking to see of there could be a better presentation of the units and services in a network, e.g. in Konqueror, Dolphin and the filedialog. I was at least impressed by the environment view of Sugar.
Before I ported the SLP kioslave I had made myself a little familiar with the zeroconf kioslave residing in the module kdenetwork, for the Zero Configuration Networking (Zeroconfig). Perhaps I can take up, where Jakub has stopped previously, and move all service discovery services (recursiveness ahead) behind an abstraction/wrapping layer, best support for multiple backends at the same time.
In the end I hope to reach a system in which programs that support realtime collaboration on the same data do not need to provide a second selector view to choose the document to connect to, but can just reuse the filedialog. Or get started from the “file” manager by a click on the relevant service item.
There are lots of possibilities in this area. E.g. you could checkout a module from a repository to a place on your disk with one drag. Just let your imagination roll what is possible…
Our friends in the GNOME camp are already some more happy camper with regard to realtime collaboration. See for GTK+ getting support for MPX, the same for Vino for a multi-pointer remote desktop, the GTK+-using AbiWord getting support for the Telepathy tubes, or just the working Gobby.
At least concerning Gobby there is hope for KDE, see some recent update on the state of Kobby. And then there is the Teamwork plugin for KDevelop, but I haven’t yet managed to get it running. My plans for Okteta in this regard are stalled a little by the work on the service discovery, but it’s them which are driving me there 🙂