First release of Cagibi, prototype of cache/proxy daemon for UPnP device listening and publishing

What?
Cagibi is the prototype (in progress) of a cache/proxy daemon for SSDP (the discovery part of UPnP).
Starting with upcoming KDE SC 4.5 the network:/ kio-slave (from kdebase/runtime) will optionally use this daemon to also show UPnP devices/services in its listing of the local network: If the UPnP (root)device (e.g. a router or a media server like on the PS3) offers a web interface, the network:/ kio-slave will forward to that url on a click of the item in the listing.
(There is no build-time check for it in the network:/ kio-slave code yet, as well as no pkg-config support in Cagibi. It’s an optional run-time D-Bus dependency, if not existing just silently ignored by the network:/ kio-slave system)

Where?
Cagibi 0.1.0 tarballs can be downloaded from stable/cagibi at the KDE ftp server (please consider using one of the mirrors).

Why?
As the network:/ kio-slave so far only supported services as reported from DNS-SD/Zeroconf via the Avahi daemon on GNU/Linux (as wrapped by KDNSSD in the KDE platform), it was obvious to me that such a daemon approach should be also done for SSDP, both for listening to service/device announcements and publishing our own.
So far these FLOSS implementation of (parts of) the UPnP specs have passed my eyes, the UPnP protocol stack frameworks/libs

the media servers

and the stuffed UPnP device racks/server suites

  • Coherence (custom code stack)
  • Rygel (GUPnP)
  • Just, they all did the SSDP stuff inside a lib/the program itself, so in case multiple processes which are using that lib will be doing UPnP stuff, they will duplicate resource usage a little. Especially unneeded as there is usually already a daemon like Avahi running, which could do that.

    It may be a small optimization, but IMHO still valid the work, e.g.:

    • a cache is faster, you do not have to wait for the broadcast answers on the startup of your SSDP client, where answers might be late as in 3 secs
    • the daemon as the only one interfacing to network regarding SSDP would run as system user with almost no rights, so exposing less of a risk
    • no need to run a UPnP device server process all the time just to send the alive message once in a while (wakeup on port activity by inetd or daemon)
    • would be a single network/cpu heartbeat instance for publishing alive messages for multiple local UPnP device offerings or receiving broadcast messages not interested in
    • ?

    And now?
    If you are a packager, please package Cagibi and add it to your distributions, so at least users of programs built on the KDE platform >= 4.5 can also see UPnP devices in the KIO system and open their web interfaces.

    If you are a developer of a UPnP stack module/lib, consider to use Cagibi as backend to your SSDP API. Even better, pick up the code and run with it, make a better Cagibi yourself, also adding the support for publishing. And even better, go for Avahi and beg for an extension for SSDP 🙂

    If you are me, you make Cagibi for the next version install on the system bus, so the daemon instance gets used by all users on the device, also change description data in D-Bus API to a string map of variant data types for better backward compatibility, in the future 🙂

    And if you have a comment, post it 🙂 (or “Leave it”, like WordPress says)

    Akademy, development catalysator

    While most of my fellows at Openismus are currently in The Hague for the GUADEC (after all those who are there are Gnome users and developers 😉 ) I got aware that this year’s edition of the conference for users and developers of KDE software, Akademy, is already a few weeks ago again, time to complete and dump my blog entry about it. (And time to welcome next year’s joint event, so all Openismus people will be at the same place at the same time 🙂 ).

    After more than two month with almost no work on KDE stuff (due to broken backlight on old laptop, starting as employee at Openismus and for this moving to and settling temporarily in Helsinki, getting a new shiny laptop but with completely broken kernel drivers for the GPU) I was happy to be able to dedicate my full time to KDE stuff again, by rushing some development setup onto the laptop I temporarily have for work and start hacking on the things that had been stuck over the recent month, especially with all the people around I need to talk to for that:

    Okteta plugin to KDevelop
    I had started that plugin at the Kate-KDevelop sprint this February. It was basically working already, but there was no way to actually trigger the loading of any file as byte array, and without any sufficient clues about the architecture and not much time to do the needed communication via email and irc this integration plugin just bitrotted in playground. Now with Alexander Dymo and Millian Wolff sitting just at one of the other tables I was a matter of preparing my questions for them (and solving part of the problem myself, as you do usually) and some little conversation, and done it was. The only showstopper are a bug in the KDevelop platform itself, worked on, and needing to wait for the SC 4.5 release next month, as only then the headers of the Okteta libs are published, which these plugin uses.

    network:/ kio-slave
    This kio-slave is part of the SC since 4.3 (in kdebase/runtime, try network:/), but since then lacking further polish and better integration with Places, bookmarks and the remote:/ kio-slave. At least one one of the biggest hurdles, the overbending of the KIO concepts, by introducing mimetypes for the service items (for a nice representation in the view), which on a click forward to a proper url of that service, which may deliver an item of another mimetype, but that is not expected.
    I was lucky to find time slots at one of the clones of David Faure present who showed his deep code knowledge and quick solution ability. So starting with the RC3 the network:/ kio-slave finally starts to get usable and can be promoted a little more 🙂

    Cagibi
    Claiming that the network:/ kio-slave was just sitting there and lacking further polish is only telling half of the truth. Last october at a sprint in Barcelona with the nice boys from Coherence I did an initial implementation of a UPnP backend, so also the devices/services as announced within the UPnP system are listed in the network, at least their root device with a link to the device’s webinterface if present (presentation url).
    Since then some time has passed, and as I needed only the SSDP part of UPnP for the network:/ kio-slave, running a feature-full daemon like Coherence was not the best solution, so under the name Cagibi I threw together some custom code for a prototype of a SSDP cache/proxy, as also once upon a time proposed by Armijn Hemel, the long-time pusher for UPnP support in KDE.
    With Armijn present, I could demo it to him, so he could see first fruits of his (and Adriaan’s) sprint sponsoring efforts related to this. How and when you can see it (like in SC 4.5 ?), will be topic of the next post.

    I also was glad to meet, amongst others I was glad to meet of course 🙂 , Nikhil Marathe, who works to finally bring the UPnP mediaserver kio-slave into existence as his GSoC 2010 project, being mentored by Bart, who started on that during the sprints with Coherence. And so Nikhil can demo more fruits, and they look tasty. The days are counted at which you cannot access your files on your X-Box (or whatever closed system you have exposing a UPnP mediaserver) from Amarok, Dolphin or any KDE platform filedialog.

    And I got a lot of inspiration from all the workshops, for going on with going Mobile, for getting our personal and open share in the Cloud, for linking our minds and data models with Telepathy, and what not.

    This year’s Akademy was great, thanks again for everyone involved to make it happen as it did!

    Going to Akademy

    Meeto! Eh… Me too! Just a train ride of less than 2 hours away, and with travel and accomodation for the full week happily sponsored by my employer Openismus

    Having dropped from KDE development for the last two month, I still have all my plans and hopes for future work at least on Kasten and Okteta 🙂 So I am looking forward to meet old and new KDE fellows in Tampere and to talk about how to make our hardware, small and big, a better tool to use.