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

[Kevin Ottens]

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

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

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

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

> 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
-------------- 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/20100330/bd758e59/attachment.sig>