I noticed that it looks like you are using a copy of the mDNSResponder code provided by Apple. It has been suggested many times before that the Gnome Desktop should have a "standard" mDNS library, and I believe the code has been started in the gmdns CVS module. It would be nice if Rhythmbox would use this library (or even some other arbitrary library) for the mDNS part, which could perhaps lead to adoption of mDNS in other Gnome apps. It does make sense to me to separate out the mDNS implemntation from the actual DAAP implementation. Mason On Tue, 2004-03-02 at 14:22 +1100, David Hammerton wrote: > 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 > > _______________________________________________ > rhythmbox-devel mailing list > rhythmbox-devel@gnome.org > http://mail.gnome.org/mailman/listinfo/rhythmbox-devel
This is a digitally signed message part