GoSoC 2009 UPnP Proposal -draft 2

[Ian Monroe]

On Sun, Mar 8, 2009 at 9:13 PM, Jeff Balinsky <jebsky at gmail.com> wrote:
> Hello again
>
> First I must thank those who have given me feedback
>
> I have rewritten my project proposal using said feedback.
>
> It is not done. But this one feels a lot better than the first one.
>
> Amarok UPnP support
>
> Jeff Balinsky
>
> Summary
>
> Many modern home entertainment devices (most notably the Xbox 360 and PS3)
> have the ability to play content of of UPnP shares. In the public domain
> there are several backends allowing a user to set up a mediaserver on their
> linux pc (coherence, ushare) and others allowing the browsing of and
> rendering of those shares(coherence, djmount).
>
> UPnP is a standard maintained by the DLNA (digital living network alliance).
> The standard has several types of devices. Most notable for amarok and this
> Project are:
>
> UPnP MediaServer ControlPoint – this is the client device class. It can
> auto-detect servers on the network in order to browse and stream content. -
> this is the goal of this project
>
> UPnP MediaServer DCP- this is the server device class that shares and
> streams media. - this is a secondary goal of this project.
>
> Rendering devices (UPnP MediaRenderer DCP, UPnP RenderingControl DCP) – this
> functionality would likely only be useful to a relatively small niche and
> most probably is beyond the scope of this project
>
> Goals
>
> The primary goal of this project is to add the functionality of an UPnP
> MediaServer ControlPoint to amarok. Thus allowing the playing of media off
> of servers on the network. This would make amarok much more useful and
> robust especially on systems which contain no local media(notebooks,
> netbooks, workstations, etc). The goal is for full DLNA compliance*.
>
> The secondary goal of this project is to add the functionality of an UPnP
> MediaServer DCP which would allow amarok to share its local collection over
> the network. This would be very useful to users wishing to play their music
> on their home theater systems via their Xbox, Playstaion or other compatible
> device. Also this will allow the sharing to other installations of amarok.
>
> Anything I manage to accomplish past this is to be considered icing on the
> cake.
>
> Details/Implementation
>
> Coherence (http://coherence.beebits.net/) is to be used as a backend for the
> implementation of this project. It has “an emerging DBus API”. It is to be
> used by kdelibs for a KIO slave and is multiplatform. I am told that I will
> need to work with the coherence developers in progressing their API.
>
> For the DMS browsing I will need to write a new Collection and Media class*.

yep!

> I will implement the DMS I will write a script. This allows it to be
> optional for the end user and also allows it to be upgraded fairly easily.

I think this is a good idea. This will probably require writing some
new QtScript binding for QueryMaker The QtScript Qt api is probably
the most complicated Qt API there is :) but luckly for you I actually
understand it now (unlike last summer, just ask poor Peter :P) and
would be happy to help you out.

> Fuzzy Work Timeline
>
> GoSoC Has two evaluation deadlines midterm in early July and final in late
> August thus I will probably split this in two parts
>
> (to attempt to do this at this point I feel is slightly premature)

We do want a detailed timeline by time you submit the final proposal.
Don't worry about it being correct: we entirely expect changes to the
timeline. But its an important starting point to have a timeline to
modify. :)

> But so far from what I have looked into I will probably (in the beginning)
> go through chronologically through the steps in the UPnP protocol:
>
> Discovery
>
> Description
>
> Control
>
> Event Notification
>
> Presentation
>
> Qualifications

I think you're thinking too low-level for this timeline. Like with
most things in Amarok I think this can just be reduced to making API
calls from a library that will do the heavy lifting. In this case I
think we can just use Coherence. You might look into Coherence's D-Bus
API to make sure its complete. If its not, its possible you might need
to code up some python. :) But even then you don't have to worry about
UPnP networking, just binding the python api to a DBus API.

So really: you're timeline should be more Amarok and
Coherence-oriented and less UPnP oriented. The ControlPoint will be a
new Amarok collection like you said.

Maybe I'm wrong though. One idea is to hack out a little Qt CLI app to
poke the Coherence API so that you can have the Coherence API figured
out before you start getting into Amarok collection implementations.
Remember you aren't bound by such decisions made in your proposal. :)

> In the fall of '09 I will be a senior CS major at Hood College
> (http://cs.hood.edu). I have been programming for about 5 years through high
> school and college. I am currently using Qt and C++ and am comfortable with
> both. The idea of using kdelibs doesn't particularly bother me. I consider
> myself functionally knowledgeable in networking and data com theory. I want
> to do more network type programming.
>
> The asterisks * denote somewhere where I need to do research to elaborate
>
> my current to do list for this proposal finishing this proposal is:
>
> -get myself where I can view/edit/compile the amarok code (any and all help
> welcome)

Good idea. Just let us know if you have trouble, it should be pretty
straightforward.

> -find the specifications for DLNA compliance

Hopefully coherence will deal with this sort of stuff?

> All feedback welcome/helpful. You are not going to hurt my feelings.

Hehe.