[GSoC] Preliminary UPnP support proposal

Wed Mar 24 13:23:27 GMT 2010

Hi Nikhil,

(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])

[B] http://frinring.wordpress.com/category/network/upnp/

Dimanche, le 21 mars 2010, à 16:15, Nikhil Marathe a écrit:
> Hi,
> 
> 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 
to implement.

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 [1] 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 
email).

[1] http://www.mail-archive.com/kde-hardware-devel@kde.org/msg00358.html

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 
ideas here?

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 
resolution).
So it could be 
	upnp-ms://ip-address:port/your_mapping_to_path_here?action=list
which would return a file with some defined format describing the variants of 
a certain file, and 
	upnp-ms://ip-address:port/your_mapping_to_path_here?action=get&id=xyz
would get you a certain variant with id as found in the variant list,
while the plain usage would for
	upnp-ms://ip-address:port/your_mapping_to_path_here
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
>  Play.

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

So you might need to update your proposal a little based on this.

Looking forward to see you working on UPnP (MediaServer) support! :)

Cheers
Friedrich

-- 
KDE Okteta - a simple hex editor - http://utils.kde.org/projects/okteta