Attracted by virtual constructs

October 13, 2009

UPnP devices coming to the network:/ kioslave

Filed under: KDE, Network, UPnP — by frinring @ 9:48 pm

Since the Coherence/KDE sprint (Spain, 26 °C, sun), where work was done for some UPnP bindings for KDE, a week has passed (Germany, 4 °C, rain/hail). Besides the weather some other things have changed that week, too, but for the good :)

While on Day 1 of the sprint I already managed to have first UPnP devices show up in the network:/ kioslave, it was done with hacky prototype code, to have some things working to start from. Day 2 didn’t change much in that regard.

The days since then Frank Scholz, the main developer of Coherence, has been very supportive and has continued adding needed features to the D-Bus API, and I have hammered a little more onto the code for the UPnP backend to the network:/ kioslave. To much success! UPnP devices are now coming and going in the network:/ listing, matching the real devices’ behaviour, with proper name and type.

All that is missing to my full pleasure is the usage of each UPnP device’s custom icon (So if you know how to set custom icons (i.e. not by name, but delivered from remote, cmp. favicons) for UDSEntries in a kioslave, please tell me!). And forwarding to the presentation url of the UPnP device, if available, but that looks like it needs some discussions with the KIO developers, because of the “abuse” of KIO for the network:/ kioslave.

No screenshot today, if you are interested please try it yourself:
The UPnP backend for the network:/ kioslave is based on the utility libkupnp which cares for the wrapping of the D-Bus connection to Coherence. So fetch both
libkupnp at
http://websvn.kde.org/trunk/playground/network/kupnp/
and the UPnP backend at
http://websvn.kde.org/branches/work/network-kioslave/adding-upnp-backend/
and compile as usual.

You also need a current version (>=#1440) from trunk of Coherence:

svn co https://coherence.beebits.net/svn/trunk/Coherence
sudo python ./setup.py install

(No idea how to install Coherence to a user-only prefix, hints welcome!)

If you are interested in Bart's work on UPnP support for Amarok, do not miss his last blog entry (which seems to have missed planet KDE).

The coming weeks I will see if libkupnp can be extended to be useful for other code interacting with UPnP devices (at least from a UPnP control point's view). For a start I will try a InternetGatewayDevice proxy class, which could be used by programs wanting NAT traversal (Konversation and KTorrent already have some custom implementation, but this could help others). Next would be a MediaServer proxy class, perhaps that could simplify Bart's upnp:/ kioslave.

October 9, 2009

Coherence/KDE sprint Day 2

Filed under: KDE, Network, UPnP — by frinring @ 2:12 pm

Exactly one week already has passed since I arrived in Barcelona for the Coherence/KDE sprint, and almost four days since I left again, so before it is out-of-date here a short summary of Day 2 (see also Day 1 for some introduction):

Everyone continued hacking on his stuff, e.g. Bart on his kioslave for UPnP MediaCollections, to be used especially by Amarok, and me on the UPnP backend for the network:/ kioslave. Which also involved discussions with Frank about shaping the D-Bus API of Coherence to our needs a little. And how to merge best the UPnP device/service model and objects into the network classes model of the base library of the network:/ kioslave, along with the ones from DNSSD and Co. This merging needs more thoughts definitely.

Lunch was cared for by our host Edward Hervey from Collabora Multimedia leading us to another non-tourist restaurant with good food and local atmosphere.

Other stuff that day was done was demoing the things now working, like the Coherence plugin for the Spykee robot delivering pictures from its built-in webcam via UPnP. Or things that have been working for a while, like each one playing his favourite songs via UPnP on Frank’s computer, in a kind of battle style. Including controlling the volume from remote.

Zaheer, Konqui and me looking what Frank does that makes him wear the K-scarf this way

Zaheer, Konqui and me looking what Frank does that makes him wear the K-scarf this way

In some way Coherence is to UPnP what Avahi is to DNS-SD, a demon wrapping the specific system and making it accessible via D-Bus. Just that Coherence does a lot more, as UPnP is not only about discovery of services, but also of types of devices and the interfaces/services they implement and how to access them.

As the developers of Coherence are using GNOME-centric desktops the current desktop integration is basically done for GNOME programs, like Totem, Rhythmbox, and Nautilus.

Let’s hope KDE-Libs based programs can catch up to these :) This was the very purpose of this sprint, and it gave a good foundation. It just left us with quite some work to do. Especially Bart might appreciate help with his kioslave, as he is short on time. So if you want Amarok to as well access other UPnP MediaCollections as well as export it’s own collection as such in the next time, get in contact with him.

I think I might be able to get the integration into the network:/ kioslave done in October (promises, what promises?). Surely there will be the need for feedback. So please stay tuned, more detailed info about approach and progress to follow…

October 4, 2009

Coherence/KDE sprint Day 1

Filed under: KDE, Network, UPnP — by frinring @ 10:30 am

Big splash for yesterday evening: “Breakthrough in the hotel!”

Barcelona, wonderful city. Crowded with a lot of people, enjoying the life style and atmosphere. This weekend there are six people more, but here for hard work, to do some collaboration on UPnP support in FLOSS software. So is there a better place to stay at then the Collabora Multimedia office here in Barcelona?

Together with Bart Cerneels, from the Amarok crowd and to most of us known as the great organizer of Akademy 2008, I am here to write code to connect to the UPnP world, by using Coherence. If you haven’t already heard of Coherence before, it is an well developed UPnP-enabling framework, written in Python and accessible via D-Bus by any other program, hiding the UPnP complexity both to the providers and the consumers of UPnP services.
So e.g. Amarok could easily offer access to its own media collections for any UPnP capable client on the network as well as access those of others, at the same time control any other player in the network (MediaRenderer in UPnP terms).
And it is also a comfortable way to add a UPnP backend to the network:/ kioslave, so the UPnP-only devices and their services are also listed there. I was hoping someone else was going to do this, but, well, scratch your itch…

Still it feels like boring work to do compared to what some others sitting at the table with us are doing: There is Philippe Normand who is working on tubing UPnP over the intertubes with the Mirabeau plugin to Coherence. And there is Zaheer Abbas Merali, who is wrapping standard UPnP services around little next-generation-mars^W indoor robots, so you can access the robot with any standard UPnP client (like the PS3, PSP or XBox). Then there is Sebastian Pölsterl who works to build a UPnP supporting personal video recorder (PVR) based on his DVB-Daemon.
Last but not least with us are Frank Scholz, the founder and main developer of Coherence, and Benjamin Kampmann, official vice-president of marketing for Coherence.

I had a quick start with the code Adriaan de Groot had written at the first Coherence/KDE sprint in Paris this spring. Still I had nothing to show when we left the office in the evening. But when most of us went to spend much money to watch 22 men catch a single ball, just to kick it away again, Bart and I waited for them in the hotel, typing even more code and then, the breakthrough, at least for me:

And it comes with congrats to Ahmed Moustaf! His computer was the first to appear in the network:/ kioslave by being feeded from the Coherence-driven UPnP backend. Sitting in the hotel room I had no longer all the devices available like we have with us in the Collabora office, but another friendly, although unknown person had his computer broadcasting his UPnP services, so there was content. You won’t see from the documenting screenshot it is from the UPnP, as that is one of the targets of the network:/ kioslave, hiding all the unneeded technical details from the user. And his computer disappeared soon after when I wanted to screenshot some UPnP only listing, was it because we started to browse his media collection and he found out?* ;) So just believe it :)
First device in network:/ kioslave delivered by the UPnP backend

*Because if there is one thing which seems to suck with UPnP it is the lack of any access control built into the system. Everybody can access everything. Well, hopefully soon KDE programs can, too :)

April 20, 2009

Network:/ kioslave entered kdereview

Filed under: KDE, Network — by frinring @ 10:56 pm

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.

The network:/ Kioslave

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. ;)

February 18, 2009

Feedback for the network kioslave, please

Filed under: KDE, Network — by frinring @ 12:11 am

Two things that cheered me up today:

1. A really interesting interview with two developers of Étoilé. I think they are so right with their approach. The application-centric approach sucks a lot and is one of the biggest culprits of the sad state of the personal computer interface still after four decades since the so-called mother of all demos, from 1968 (sic!). Since I first heard from that project three (already?) years ago I have been checking their homepage for news every week :) Definitely a project to watch and learn from. If you look closely at the Okteta sources, the Kakao part, you might even see where I try to lay the base for something remotely similar to CoreObject. And a project to join? Hm, if I would start with FLOSS I would definitely try to work in that project. But I am now engaged with KDE, which also is going some good directions :)

2. A really big Multiseat deployment in Brazil, with up to ten(!) workplaces per mainboard. No idea, if they are using KDE. But I feel so inspired by the technical approach, and still feel sorry I once failed to setup a multiseat myself (due to X drivers of the graphic cards surprised to not be the only graphics card on the same PCI bus and by this confused, or something, memories are fading), so I could never show it at the local Linux-Info-Tag Dresden (BTW: Will you be at the Chemnitzer Linuxtage, 14.-15. March? KDE will be there, thanks to Palapeli-Stefan and others).

If they are using KDE, I am wondering what the output of the network kioslave would be and how it could be improved.

Now, you can cheer me up, too:
Just give some ideas how you would want network kioslave to work like. Go and try it, should also compile with KDE 4.2:

svn co svn://anonsvn.kde.org/home/kde/trunk/playground/network/networkkio
mkdir build
cd build
cmake ../networkkio
make
make install

This will install a kded-module for kio-updates on changes of the network, a solidnetwork library, the network-kioslave and some mimetypes for known services.
Some of the services are for now simply subtypes of the types directory or symlink, so clicking on it should forward to the url that is attached to them. You can also redefine the handling with the usual file association dialog.

Even better, join the coding, I welcome everyone to write the backends for UPnP, WebServices, Lisa-like scanning and what else there is that could be shown in the network.
I also would like better code for the device type detection. Are there any services which would help to see if a host is a big server, a laptop, a netbook, a router? Perhaps even the model, like Producer Cooldevice 2010? Currently I plan to go for heuristics by found services, but I wonder how it is done in Windows or OS X if listing other devices in the network.
Then a config would be nice, to limit the number of service shown (and hide the unknown optionally). Also to define which other domains than the local network should be scanned.

February 13, 2009

Browse your network

Filed under: KDE, Network — by frinring @ 9:25 pm

Have you developed a network service, used DNSSD:: PublicService to publish it with the zeroconf system, and then wondered why it didn’t show up in Konqueror with zeroconf:/ from the kdenetwork module?

I did. And found out that the zeroconf kioslave restricts itself to filesystem services and redirects to the listing of the services for convenient browsing of such filesystems. It also orders the listing by the service types in the first level, not the hosts. Which is nice for that, but not what I was looking for. I wanted to see all devices and the services in the domains I care for, like lan:/ might have done (if it ever had worked for me), I only know it from screenshots, like this one :)

So hands on, write your own, brave man. Followed that, so find the prototype code in playground as network-kioslave. It also includes a library which might develop into something general to be added to Solid. But let’s wait for that. There is a lot of stuff that needs to be done, integrating the different service lookup systems, finding a general model for all them, and much more. I have first-hand rumors that others are starting on support for UPnP, so I am looking forward for some cooperation where possible. If you are experienced with samba, please contact me, too.

See a lovely screenshot in the style of the season (isn’t it always this season?) for what already works. As backend KDNSSD is used, and then quite some guesswork happens to generate a device and service structure from the info available. But it’s a start:
Browsing the network with the network-kioslave
Nothing much to see, the local network is pretty empty currently, just a lonely router and my computer… And the one on it offering KBattleShip is myself, so nothing to distract me ;)

Clicking on the services shows where I am currently stuck. A service item represents a service running on a host at some port (or even ports?). But what to do on this service? E.g. the ssh service could be used to open a ssh-session in Konsole. Or be used for browsing with the “fish:/” kioslave. A database service could be either queried or configured. So just doing a redirect to another protocol is not what I want here. Instead there should be some new mimetypes one could register clients/handlers for. So in the context menu you could choose another option than the default one. Would also be nice for metadata display. I already install some new mimetypes for network services/devices, but the naming pattern might need some discussion. And xdg spec support. Much to be done…

February 4, 2009

Bonjour, what services are in this location?

Filed under: KDE, Network — by frinring @ 11:59 pm

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.

So far it’s a 1:1 port, perhaps with new bugs introduced by the port:
SLP kioslave ported to KDE 4

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 :)

Powered by WordPress.com