[Kde-hardware-devel] [GSoC] Preliminary UPnP support proposal

Wed Mar 24 15:56:18 CET 2010

On Wed, Mar 24, 2010 at 14:23, Friedrich W. H. Kossebau
<kossebau at kde.org> wrote:
> 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.

Hehe, indeed. I would say a MediaServer is the only UPnP device type
suited to be represented in a filetree. Friederich has successfully
stretched the filesystem paradigm to suite network device discovery as
well. So I understand that viewpoint but still don't agree with the
proposed protocol prefix.

Since mediaserver is by far the most used UPnP "filesystem like"
service I propose we use upnp:// for mediaserver. Other (future) upnp
kio-slaves can use something like upnp-dsc://, etc. Since the
kio-slave feature is already hard enough to discover, we shouldn't
make guessing the protocol part any harder.

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

True, each content-directory item can have multiple resources each
with a different ProtocolInfo PI is a combination of mimetype and
transfer method and can contain optionals such as DLNA flags. Ex:
http-get:*:audio/mpeg:DLNA.ORG_PN=MP3;DLNA.ORG_OP=11;
DLNA.ORG_FLAGS=01700000000000000000000000000000

It's a common practice though to only have one resource per item,
usually a direct http link to the file on disk. DLNA also mandates
that the first resource is the default and that it should not be
generated (transcoding) or on the fly content.
The only resources the upnp kioslave is interested in anyway are http-get.

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

This won't be an issue since all UPnP servers, and certainly the DLNA
compliant ones implement ContentDirectory::Browse and have both direct
access to the files as well as virtual folders based on metadata:
Artist, Album, Year, CameraType, etc.
Browsing both is exactly the same.

> 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.
How about we just pass resource info in the KIO::MetaData of an item?
It's the obvious thing to do for the normal metadata embedded in the
XML document returned by Browse and Search. But we can list the
available resources as well, in the same order they are listed in the
XML even. The first one being the standard resource returned when
browsing normally.
Accessing the data of those resources (if available as a bytestream)
can be done using the query like you suggest. It would look more like:

(upnp://<ipaddress>:<port>/<device-UDN>/<itemid>?res=<ProtocolInfo>)
upnp://192.168.1.2:30020/e0c975b9-753b-466f-9f5b-56d978a29fd8/12519.flac?res=http-get:*:audio/flac:*:

or a more human readable alternative:

upnp://192.168.1.2/Music/Artists/Stream%20of%20Passion/Embrace%20the%20Storm?res=1

Both should be supported, one for applications and internal function,
the other is to be used by a human user and clearly represents the
browse path and will in most cases match what is on the disk of the
mediaserver. The second will need to be mapped to an internal
structure like the first before the content can be fetched.

>
>> 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
> _______________________________________________
> Kde-hardware-devel mailing list
> Kde-hardware-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kde-hardware-devel
>