On Mon, 2004-03-01 at 22:22, 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. You appear to be doing a pretty good job documenting it. One thing we (JuK and Rhythmbox) could do is just take your reverse engineering to be the specification, and your library to be the reference implementation. If iTunes changes things later, at least free clients will still be able to interact. Scott? What do you think? > 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. Fair enough. The idea of codec negotiation would allow for at least better interoperability between say an instance of JuK that's sharing MP3s, and an instance of Rhythmbox which doesn't have MP3 decoding support (as will likely be the case for most Fedora installations...). On the other hand, a few transcoding processes could get pretty bad for the server. So yeah, let's put that idea aside for now. > 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? As long as your library can safely be run in a separate thread, I don't see any problems. > 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. No problem, at least in Rhythmbox we'd likely just use another thread. > 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. Yeah, but we already have infrastructure in Rhythmbox to handle that.
This is a digitally signed message part