Network:/ kioslave entered kdereview

While today those lucky enough to be chosen for participating in GSoC can start their activities, we all wish them much fun and pleasing results, others can mark an end to a period of development: Not just kdelirc did enter kdereview and now awaits your critics, also did a so-called network:/ kioslave I have been working on in the last month.

Read on for some background about this kioslave. This text had been written for the Commit-Digest but did not make it in time for the latest one:

Concept

The network:/ kioslave offers the listing of the network from a general point of view. It should map the physical world as much as possible, with all the devices and services. The main purpose is discoverability of what there is around the computer and object-oriented access to it.

It is a little bit in the tradition of the lan:/ kioslave, which is driven by LISa, but unmaintained for KDE 4. While LISa in it’s time basically had to use pinging, the network:/ kioslave now can use backends for the modern service discovery systems like zeroconf.

Design

The network kioslave currently consists of four parts:

• a library named network, which models the devices and services, driven by backends for the various service discovery systems
• a mimetype definition file, which adds types for the various devices and services
• the kioslave itself
• a kded module to emit proper KDirNotify signals if the network structure changes, so all views using the network:/ kioslave get updated

Both the kioslave and the kded module link to the network library. Due to synchronisation problems the kioslave currently pulls the needed data from the kded module using D-Bus, instead of directly using the network structure in the linked-in network library.

Status

The kioslave is already quite usable for networks with devices using zeroconf, like there is with KDE programs using KDNSSD/Avahi or all Apple computers. Even reacting to (dis-)appearing of services and devices seems to work flawlessly now.

All service types are currently simply forwarding to the corresponding url, if there is one. So for services which have direct support in KDE for the used protocol, like webdav, http, ftp, svn, ssh or vnc, you can click on the service item and then either find yourself listing the files, browsing html pages, login to the shell, or whatever this service and the (KDE) clients enable you to.

For some servicetypes you first have to assign yourself a handler, if the mimetype for the service could not be derived from a matching one, like inode/directory. For this goto System Settings>File Associations and see for “inode/vnd.kde.service.*“. E.g. for “inode/vnd.kde.service.rfb” add “krdc -caption "%c" %u” (%u is important) as application handler. So clicking on a rfb service will start KRdc for that service.

A little bit annoying can be that there is not yet a configuration to filter the presented services, e.g to hide all system-level and unknown service types.

And, might be a stopper for some, Dolphin and the Plasma Folderview widget do not cooperate too well, they often show some error messages if launching remote urls. So just use it in Konqueror for now 🙂 Well, other non-file kioslaves are affected as well, so one should see after that.

Future

Wide, wide open.

More backends are needed, for UPnP, SMB stuff and others. There is already a rudimentary backend for SLP, but this crashes due to threading problems (the kioslave ran the network library in a separate thread, until the current synchronisation fix with the D-Bus pulling was switched to), so the zeroconf one is the only working backend currently.

Supporting the display of the status of the service needs support, e.g. updating on the presence change in a Bonjour Chat service. And getting some Meta information for services to display, here the name and such.

Then I am looking for a service which can help to identify device types properly (printer, router, computer, laptop, phone, or handheld, perhaps even manufacturer/model). Currently the type is guessed by the services running,
which is not really perfect. Also it would be nice to have individual icons for the devices to display, similar like favicons are used for web services.

Next, things like virtual machines or PDF “printers” bear some challenges how to present them best. In general there needs to be a definition for what system is a device and what is a service. In that process the mimetypes for the services and devices also need some rethinking.

Also the network library needs to be checked if it could not end as a generic library to end in Solid or another place. And could substitute KDNSSD with a generic interface to publish objects/systems to the net or query/get proxy objects for systems on the net, including WebServices ( see also similar ideas from Jakub).

Furthermore, all programs which can connect to a remote source need to expose this capability also on the commandline, so they can be started explicitely for a given service. E.g. some KDE games are network enabled, but do not yet support to connect to a remote game by having the url passed as a commandline argument. I did a quick example patch for KBattleship, but it seems I need more motivating material for the KDE games developer 😉 At least this particular patch is now committed (during the Chemnitzer Linux-Tage I demoed the network:/ kioslave to Patrick and Eckhart at the KDE booth, which resulted in a KBattleship tournament, won by Eckhart with easiness.)

And in the end I would like to have some more spatial oriented views for hierarchical items, based on concepts found in the environment view of Sugar and the Semantic Desktop DeepaMehta, best automatically structured by using the geo information of the devices.

Seems it will be ready next week. 😉