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

Kevin Ottens ervin at kde.org
Tue Apr 6 21:54:05 UTC 2010


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.

Agreed, it's not what we're talking about though.

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

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

> >> May - Read the UPnP standards, get comfortable with the library of
> >> choice, write lots
> >> of little code snippets to do specific things, so as to get a feel for
> >> the system.
> >> 
> >> May 15th - June 7th
> >>   Work on getting Solid backend listening to UPnP devices and presenting
> >>   them to applications/slaves. This includes writing documentation
> >>   about how to get KDE Apps to access UPnP services.
> > 
> > Here, it would be nice to make sure the integration with the existing app
> > of work correctly with the new listed devices (addressing KFileDialog,
> > Dolphin, and the Plasma device notifier).
> 
> Isn't that more solid related?

It is, hence why I said my proposal was to broaden the scope a bit.

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

Sure, I didn't expect write support in this ioslave anyway be it at least for 
security concerns. Since AFAIK UPnP is rather weak for its authentication (to 
say the least).

> And there is
> also a conceptual problem in mapping mime-types to didl-lite content
> classes. It's easy for audio, video & photos (still depends on
> advertised server source ProtocolInfo though) but what about other
> types like PDF, txt files, ... Is there a KIO way of preventing
> non-supported filetypes to be copied other then failing with a write
> error?

Not sure I'm following here. You're talking about the write support which 
isn't going to exist anyway? Then yes, it's mainly about giving back an error.

> > Here I'm not fully sure what you've in mind, but I would make it slightly
> > more precise. In particular (and the Amarokers can prove me wrong here),
> > there's likely almost nothing specific to UPnP in this upcoming
> > collection, really technically it's a kio based collection, and maybe
> > that's an aspect you could push forward (I'd expect it to work for upnp,
> > sftp and so on).
> 
> It will be very tied to the KIO-slave implementation actually, since
> KIO does not have a standardized query method, and UPnP also has
> sorting, filtering, etc. So we rely on those to be implemented in a
> certain way. It's not as simple as using a generic KIO Collection.

Except if the querying is standardized on the KIO side. Actually for the 
sorting and filtering it could probably done today using the meta data 
mechanism. Query method would probably require further work.

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud patron of KDE, http://www.kdab.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/amarok/attachments/20100406/a70a87fd/attachment.sig>


More information about the Amarok mailing list