[Rhythmbox-devel] Re: Functional DAAP client code
- From: David Hammerton <david craz net>
- To: Scott Wheeler <wheeler kde org>
- Cc: rhythmbox-devel gnome org, aseigo kde org, egwynn andrew cmu edu
- Subject: [Rhythmbox-devel] Re: Functional DAAP client code
- Date: Tue, 2 Mar 2004 14:22:15 +1100
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:
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
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.
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
>> have intentions of making it work with Rhythmbox - but never got
>> to it before release.
>> Anyhow, It'd be great if you would work on doing it. It would
>> 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
>> 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
> But mostly just rambling and of course missing most of the context.
> - -Scott
> - --
> Peace and humptiness forever.
> - --Digital Underground
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.7 (GNU/Linux)
> -----END PGP SIGNATURE-----
Welfare *NOT* Warfare
] [Thread Prev