[Rhythmbox-devel] Re: Functional DAAP client code

[David Hammerton <david craz net>]

Hi Scott,

You are correct, the DAAP protocol isn't an open  protocol, however it 
is built around one (HTTP) and the proprietary 'data' blocks are quite 
well known. In fact, the protocol is somewhat self-documenting - as all 
"network opcodes", as you might call them, are reported back with their 
plain-english name using a certain GET command, see:

http://www.deleet.de/projekte/daap/?ContentCodes

DAAP also appears to be built on top of Apples 'DMAP' - which I'm 
guessing stands for 'Digital Media Access Protocol'. iPhoto, a photo 
app for the mac, also uses DMAP and an extension called DPAP (digital 
picture access protocol, I guess). (To share pictures).

I'm also all for an open protocol for Juk/Rythmbox - however I think 
you would do well to study the Apple one a bit, because IMO - they "got 
it right".
I don't think it would be a good idea to base a share protocol around a 
streaming type thing, like you suggest - as there will always be new 
music formats, and even new media formats.. Any protocol that "we" 
design should probably be able to support any of these.
The key idea behind Apples media protocol is that you simply request 
various data you want, normally meta data (what are the songs? give me 
the title, artist, album, time and size of this song,.. etc) and then 
finally request the song, in its raw audio format (ie, it really just 
sends down the MP3 file, or whatever - I guess for AAC it probably does 
this after removing DRM from it). All using HTTP GET requests.

Anyhow - back to the discussion about the best API for libopendaap that 
will suite both media players. I guess one big decision that I'd like 
some input on from both sets of developers is this:
What of threading? Currently my library makes use of threading 
specifically for Rendevouz discovery and for file getting, all other 
ops are synchronous, which could slow things down if the connection is 
slow.  However threading does introduce problems with the various X 
GUIs.. Since callbacks will come from a random thread, you can't draw 
directly from that thread.

I could make my stuff simply supply FDs or something to be added to a 
poll statement (in Glib or whatever there is some g_wait_object or 
something, which I make use of for waiting on a pipe)  -  but it may 
prove hard for the mDNS implementation I use.

Eli - I missed you last night - I'm on Australian time, so I guess 
it'll be hard to contact each other on IRC.

Cheers

David

On 1-Mar-04, at 11:16 PM, Scott Wheeler wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Monday 01 March 2004 12:18, David Hammerton wrote:
>> I'm the author of the code you mentioned in your e-mail. I did 
>> actually
>> have intentions of making it work with Rhythmbox - but never got 
>> around
>> to it before release.
>>
>> Anyhow, It'd be great if you would work on doing it.  It would 
>> probably
>> make sense for you to base your work on my library, as it seems
>> suitable for the job. However, the library isn't very mature right now
>> - as I wasn't really sure what kind of an interface would best suite
>> the current media players (Rhythmbox and Juk). As a result, I'd like 
>> to
>> work with you (and any other developers who are interested) in
>> improving libopendaap to a more than usable state.
>
> Hi David, et al --
>
> To be honest I'd really be more interested in working with the 
> RhythmBox folks
> on something similar that isn't linked to a proprietary protocol (or 
> at least
> this is my understanding of things -- please correct me if it is in 
> fact an
> "open" standard) that could be shared between RhythmBox, JuK and other 
> Free /
> Open Source software.
>
> I wouldn't mind supporting iTunes streams but I would prefer to have 
> an open
> alternative (maybe based on SLP and Ogg Vorbis streaming) in place 
> first...
>
> But mostly just rambling and of course missing most of the context.  
> :-)
>
> Cheers,
>
> - -Scott
>
> - --
> Peace and humptiness forever.
> - --Digital Underground
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.7 (GNU/Linux)
>
> iD8DBQFAQymxQu0ByfY5QTkRAuYKAJ4uQgvevxv3E9Ix/S+Y2g5aO97rUgCdG7Gz
> kOm8mNr8vUOqMPVhrslurUY=
> =xeT8
> -----END PGP SIGNATURE-----
>
>
--
David Hammerton
david@craz.net
http://crazney.net/
Welfare *NOT* Warfare