[Kde-hardware-devel] [GSoC] Preliminary UPnP support proposal
Friedrich W. H. Kossebau
kossebau at kde.org
Wed Mar 24 14:23:27 CET 2010
(cc:ing kfm-devel as this is also about kio-slaves and I might be incorrect,
please comment on that part)
good to see someone willing to work on UPnP (MediaServer) integration, much
welcome also by me :)
Read on for some comments from the one (me ;) ) who has worked on the
integration of UPnP devices/services (discovery only) into the network:/ kio-
slave and recently Solid (blog entry at [B])
Dimanche, le 21 mars 2010, à 16:15, Nikhil Marathe a écrit:
> I would really love to participate in GSoC and get KDE to have
> seamless UPnP support and allow
> Amarok to treat the network as a great collection.
Would be great if you could do that :)
> Amarok and KDE UPnP integration
> Motivation for Proposal/Goal:
> The KDE project has always been known for its network transparency and
> the kioslave concept.
> Yet as the network becomes more and more a part of the computer, I
> think it it important
> to be able to have applications also make use of this transparency.
> UPnP is a set of
> standards which allow various devices on the network to share content,
> including music
> and photos.
I completely agree with your intent to make the stuff on the network more
accessible/discoverable to the average program and especially to the user.
This is an area KDE software/workspace still can improve a lot.
That is e.g. why I have started the network:/ kio-slave last year (part of
kdebase/runtime since SC 4.3). For the next SC release it will also
include the listing of UPnP-type devices/services, this feature has recently
been added to what will become SC 4.5.
Same with Solid, there is now a (half-finished) backend added to it which
lists all UPnP devices on the network.
So the part concerning discovery of UPnP devices/types is already worked on or
even covered, you can put all your efforts in the support for access to the
media collections :)
And expect me/us to be happy about your feedback how to improve that stuff.
Now some comment about your plans:
(Disclaimer: I am no expert on this field, but learned a little already, so if
I am not correct somewhere please say :) )
If you will learn more about UPnP you will learn that UPnP is not only about
interaction with MediaServer type devices/services and their discovery. There
can be all kind of UPnP-style services/devices, like routers
(InternetGatewayDevice) or light switches (Lighting Controls), so it's not a
AV-only thing. Or whatever type of device/service you want to come up and give
it a spec. UPnP more or less just defines the discovery system and the kind of
interaction (SOAP) with the devices/services. There is also an official
collection of specs for certain types of devices and the service API they have
What you will be going for are basically the "MediaServer" UPnP devices. There
are 3 official versions currently, numbered 1, 2 and 3. You also might want to
see what (undocumented) extensions there are out there which add some kind of
ACL/DRM, like Windows Media (Player) does.
The basic architecture for UPnP support in the KDE platform from the (UPnP
control)points view as currently worked on is described following. It follows
roughly the draft  of Armijn, no idea if by intention or just because it's
a good solution :) (yes, the the reference you already gave in your other
There is a SSDP cache daemon (Coherence currently used for that). Same like
what Avahi does/is for DNSSD/Zeroconf. So all programs/libs on the local
computer system interested in UPnP devices/services just query that daemon via
D-Bus. For KDElibs based code this querying for the currently existing devices
is transparently (going to be) done by Solid, i.e. the UPnP backend to Solid.
UPnP devices are mapped to Solid objects and the Solid interfaces. So in
theory they automatically can be seen by existing programs with no change in
their code to also support UPnP-types.
(Solid as in kdelibs is basically about discovering. One task may be to
develop new Solid interfaces for aspects of the UPnP (MediaServer) devices not
covered by the existing ones.).
To actually interact with a UPnP device there has not been done/decided a lot.
In the end it might be nice to have some Solid::Control for the common device
types in kdebase, but I haven't looked in to that yet. Kevin, what were your
For the start each code has to do the interaction themselves (code can migrate
later to the Solid::Control stuff). There are two choices: speak SOAP directly
with the devices (e.g. by HUpnp) or go via an intermediator (like Coherence,
using D-Bus) who has learned to cope with all the horrible UPnP
implementations which are said to be out there (source?).
Your UPnP-MediaServer kio-slave now would be the wrapper around the (and only
those) MediaServer type devices, to make the content on them accessible to all
KIO-enabled programs, and especially Amarok. It could have the "upnp-ms"
protocol-name (not just "upnp", even if Bart would prefer this, we are
different opinion here, IMHO this would be limiting). So upnp-ms://ip-
address:port/your_mapping_to_path_here would be the urls which would be
handled by the slave. Remember one day there could be other non-MediaServer
UPnP devices which offer files. The DigitalSecurityCamera might be one
already, which would need a different protocol name for it's kio-slave. So
just upnp:/ would abuse the namespace.
IIRC the items in MediaServers collections can include several alternatives
for a media item, e.g. with different encodings or bandwidth needs, each
pointing to a different (http) url where that media item variant can be
accessed using classic http.
Usually an entry in a kio-slave listing refers to one bytestream, fetched
with a KIO::get() instruction. But not several alternatives, like with the
MediaServer. If I am correct there is no kio-slave with a similar problem yet,
so you will also have to think about how you best map the MediaServer
collections to a tree hierarchy as has to be presented by a kio-slave. If you
want to expose the different variants at all in the basic output.
One idea might be to use the query part of the url to pass some arguments, so
smarter programs which know about the upnp-ms:/ protocol can both query more
details about a file item or define which particular variant they want to
have, while all other just get a default variant (e.g. the highest
So it could be
which would return a file with some defined format describing the variants of
a certain file, and
would get you a certain variant with id as found in the variant list,
while the plain usage would for
just deliver the default variant of that file.
Remember there may be different users of a kio-slave. Konqueror is the most
prominent one, but in fact all kio-aware programs could be a user, e.g.
Gwenview for looking at a picture. The idea of the kio-slaves is that all kind
of folder/file can be accessed in a uniform way (list,stat,get), without the
program needing to know about the actual protocol/system used. Well, there is
some extra treatment for http and other protocols, but that is limited to
dedicated programs/parts. E.g. Gwenview, Okteta or KWrite do not care if it is
http or something else, they just call abstract interfaces :)
The people on kfm-devel at kde.org should know better how this can be done, what
other channels there are for communication with a kio-slave, if any.
> Amarok itself stands to benefit a lot. UPnP media devices allow a
> simple collection concept.
> I would like Amarok to have seamless integration of those collections
> into its own collections
> and support the same operations of filtering and sorting. This way I
> can have my music in
> assorted places and not worry about where it is, but just tell Amarok to
As said, it would be great if you could create something other media players
based on the KDE libs, besides Amarok, can also make use of, perhaps not full-
featured, but in a basic version (like always delivering the best solution of
a media file).
This my quickly done, not much structured comment, I hope it was
So you might need to update your proposal a little based on this.
Looking forward to see you working on UPnP (MediaServer) support! :)
KDE Okteta - a simple hex editor - http://utils.kde.org/projects/okteta
More information about the Kde-hardware-devel