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

Wed Mar 31 07:54:49 UTC 2010

2010/3/30 Kevin Ottens <ervin at kde.org>:
> On Sunday 21 March 2010 16:15:46 Nikhil Marathe wrote:
>> 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. I have been working
>> on understanding the UPnP
>> stuff and using the Hupnp library and a bit of Coherence for the past
>> 2-3 weeks, and been in contact
>> with Bart Cerneels, the prospective mentor. Based on all this, here is
>> my first draft of the proposal.
>
> Very good proposal as other pointed out. And you can tell it from the size of
> this thread... :-)
>
> ... actually I've been wondering where to chip in for a few days already, but
> just gave up and replying to the thread starter. ;-)
>
>> Note about kioslave implementation
>> ----------------------------------
>> [...]
>> Meanwhile having a library like HUpnp will keep the core pretty small.
>> It provides
>> the Control Point and device discovery support that is the basic
>> requirement for now.
>
> Note that I see a risk of going for a library without any central cache across
> process. Each application which will need to list the UPnP devices will
> trigger yet another discovery on the network uselessly stressing it.
>
> If you ditch Coherence or something else similar, you might want to
> reintroduce a way of caching the list of UPnP devices and serving it to the
> applications (being it a central daemon or an on disk mmapped cache).
>

Actually, if the discovery is done by Solid and the result is an
IP-address of a device that is known to be UPnP compliant (well, at
least it has a description), then preforming a discovery in the client
application is unnecessary. Although I should say the network load of
a broadcast discovery is laughably small. It also serves the purpose
of checking to see if the device is still active or changed IP without
solid noticing. So it's more error resistant.

Tuomo, HUPnP author, should chime in here: Is the discovery optional
or can HControlPoint be changed to skip discovery?

>> I have been in contact with Tuomo Pettinen and he is
>> working hard on the library
>> with version 0.5 expected to be out in a few days. He is aiming for
>> API/ABI stability,
>> and I'm sure that since most of the implementation will be wrapped behind
>> solid, hopefully it won't make a HUGE difference.
>
> Exactly, actually depending on how you make progress that's probably a
> strategy to keep in mind for you: concentrate on what works today (e.g.
> Coherence) and hide it behind libsolid interfaces. If you have enough time you
> can then switch to another backend (e.g. HUPnP + caching strategy). If not,
> well, no harm done you have the thing working in time for GSoC and the backend
> switch can happen later.
>
>> 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.
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.

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.

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

>
> It's probably not much work in itself IMO, but maybe we made a couple of wrong
> assumptions at some places that would require being fixed.
>
>> June 8th - June 30th
>>   Implement the UPnP kio-slave completely, ie:
>>    * Detect browsable devices ( MediaServer )
>>    * Allow querying for devices which support it.
>>    * Copying of files and watching for events about any changes in files
>>
>> July 1st - July 12th
>>   Implement Amarok Collection, which can browse servers and integrate
>>   their content so that tracks can directly be played by Amarok. Allow
>>   copying content to local collection, and so on. This is the time of
>>   Mid-term review. Ideally what will be pending now is the in-memory
>> query maker.
>
> 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.

>
>> July 12th - July end
>>   Amarok Collection supports queries. If remote server doesn't support
>> queries an MemoryQueryMaker takes over. Ensure the code works for edge
>> cases and so on.
>>   Start working on creating PlaylistProvider in a separate branch. Since
>> this is an optional part which I can continue working on after GSoC.
>>
>> August
>>   As 'pencils-down' approaches, get the code in order, clean it up, take
>> notes, clear bug reports and get ready for the merge :)
>
> Profit! :-)
>
> Regards.
> --
> Kévin Ottens, http://ervin.ipsquad.net
>
> KDAB - proud patron of KDE, http://www.kdab.com
>
> _______________________________________________
> Kde-hardware-devel mailing list
> Kde-hardware-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kde-hardware-devel
>
>