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

[Friedrich W. H. Kossebau]

Mercredi, le 24 mars 2010, à 15:56, Bart Cerneels a écrit:
> On Wed, Mar 24, 2010 at 14:23, Friedrich W. H. Kossebau
> 
> <kossebau at kde.org> wrote:
> > 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.

I do not think guessing the protocol is the problem. Ideally noone has to type 
that url, if we do our work well, right?
But people who just learn about this kio-slave by reading the name of the 
protocol (and not some longer description hidden in some manual) will think 
this kio-slave will handle all of the upnp devices (just read Nikhil's 
proposal where he also sometimes just talks of "UPnP devices" and not just the 
MediaServer ones). It is the same problem as with the zeroconf:/ kio-slave. 
What do you guess is delivered by it? (write it down, now read on)
Despite its name it does not list all of the services announced via Zeroconf, 
but just those which offer a filesystem-like service. It has trapped a lot of 
people, including the one writing here.

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

For images it might be nice to also get the lower resolution if available, for 
the preview (think of Digikam, or just the Konqueror preview).

(Hm, now that I think about it this idea slipped in: Couldn't media files also 
be handled by Akonadi? Perhaps this would be another nice SoC project, porting 
the collection handling out of Amarok to Akonadi, to enable more frontends. 
UPnP MediaServers would be just one more resource...)

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

Oh, nice.

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