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

Friedrich W. H. Kossebau kossebau at kde.org
Wed Apr 7 14:15:47 CEST 2010


Mardi, le 6 avril 2010, à 23:54, Kevin Ottens a écrit:
> On Wednesday 31 March 2010 09:54:49 Bart Cerneels wrote:
> > 2010/3/30 Kevin Ottens <ervin at kde.org>:
> > > On Sunday 21 March 2010 16:15:46 Nikhil Marathe wrote:
> > >> Tentative Timeline:
> > >> ===================
> > > 
> > > May I propose to make this proposal less Amarok centric? (in fact as
> > > the "Motivation" section kind of implied in the beginning). I think
> > > it'd be a huge win for your proposal. I'll make a couple of comments
> > > below to address this.
> > 
> > In my opinion, the upnp-slave only would be to limited for a full
> > GSoC, at least for a strong candidate. Technically it comes down to
> > parsing DIDL-lite XML.

Hm, I think the upnp-ms-slave would be enough work for three months for a 
newbie to KIO/UPnP, if the result should be complete, including write support, 
tests and docs. 
Technically UPnP (MediaServer) support in KDE would have been solved for 
more than a year ;)

> > Also from the amarok viewpoint, the kio slave is actually extra work.
> > We don't really need to use KIO, but the whole of KDE benefits because
> > we decided to do this. And hopefully we also get discovery by Solid,
> > in the same way we rely on it to detect portable media-devices and USB
> > external storage.
> 
> Obviously.

I also think this is a good approach, to share what can be shared  :)

> > Amarok needs a search interface, hence the upnp-kio slave will need to
> > implement query support. I doubt this would be developed for a
> > standalone KIO-slave.
> 
> Interestingly I think that such search interface would be a nice extension
> for KIO, and there's other collection oriented applications which would
> benefit from it (Digikam comes to my mind).

To my mind comes Akonadi/Nepomuk as the query wrapper ;)

> > If the architecture supports, or will
> > support, a kurl for the root of a device, you can just point to
> > upnp://... and the magic will manifest :)
> > Note that it's unlikely you'll get write support in upnp:// soon
> > though, there just are not enough servers supporting it.

upnp-ms: please. upnp: just is wrong here.

> Sure, I didn't expect write support in this ioslave anyway be it at least
> for security concerns.

I would :)

> Since AFAIK UPnP is rather weak for its
> authentication (to say the least).

In the base architecture. But IIUC some device types have extra services 
(APIs) to have authentication as add-on. No idea, how good these solutions 
are.
But if writing is possible it should be offered. Why limit ourselves? We also 
offer http and SMTP.

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


More information about the Kde-hardware-devel mailing list