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
- Herqq UPnP (HUPnP) (Qt-based)
- BRisa (Qt-based in a variant)
- GUPnP (GLib-based)
the media servers
and the stuffed UPnP device racks/server suites
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)
Attracted by virtual constructs 
Coherence for sure has a DBus interface that lets other apps use it to cache and scan for devices on the network. Rygel I’m not as sure about, though it does the opposite for sure (if you provide it with a DBus interface, it will publish that on the network for you).
There very well might be a good reason for a third UPnP daemon, just wondering what it is.
Cagibi is just for the SSDP part, never should do more than that.
And yes, Coherence has a D-Bus interface, I used it before I started on Cagibi. 🙂 Just the footprint of Coherence was a little too large given that I just wanted the small part of it which does the SSDP stuff.
Does this mean there will be no python interpreter running in background necessary to use UPnP in KDE? If that’s true, then this is really cool, the less scripted language components are there, the better.
Depends what you mean with “use UPnP in KDE”.
Cagibi, writen in C++ and based on QtCore/QtNetwork/QtXML/QtDBus, is all you need for the listing in the network:/ kio-slave and being able to open the web interface (web page to control the device as user at best) of these devices. No Python involved.
But UPnP is about much more. For that you need e.g. on of the listed frameworks/programs.
[…] 4.5.0 release of KDE’s fine products (the platform, the workspaces and the apps), I rushed 0.1.0 as a first version which was basically working, to be used by the network:/ kio-slave (included in […]