Re: [Rhythmbox-devel] Re: Functional DAAP client code
- From: David Hammerton <david craz net>
- To: Mason Kidd <mrkidd mrkidd com>
- Cc: aseigo kde org, egwynn andrew cmu edu, daniel fooishbar org,rhythmbox-devel gnome org, Scott Wheeler <wheeler kde org>
- Subject: Re: [Rhythmbox-devel] Re: Functional DAAP client code
- Date: Tue, 2 Mar 2004 19:25:26 +1100
Well - I would argue that gnome shouldn't have a standard mDNS library,
but rather there should be a UNIX one.
The issue is this. Since mDNS binds to a port and so forth, only one
can be running at a time.
What apple does, which is the correct solution, is they have a daemon
which runs mDNS, and then a library that talks to the daemon via RPC.
Apps that want to use Rendevouz use that library.
So anyway, a gnome solution would be half way there.. But it sort of
makes it hard for desktop interoperability, I would think that a
solution hosted by FD.O that is independent of any of the toolkits
(kde, gnome, etc) would be a better solution.
PS - cc'ing Daniel Stone of FD.O on this.
On 2-Mar-04, at 6:50 PM, Mason Kidd wrote:
> 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
> Gnome apps. It does make sense to me to separate out the mDNS
> implemntation from the actual DAAP implementation.
> 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
>> "network opcodes", as you might call them, are reported back with
>> 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
>> it right".
>> I don't think it would be a good idea to base a share protocol around
>> 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
>> this after removing DRM from it). All using HTTP GET requests.
>> Anyhow - back to the discussion about the best API for libopendaap
>> 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
>>>> - 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
>>> 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-----
>> David Hammerton
>> Welfare *NOT* Warfare
>> rhythmbox-devel mailing list
Welfare *NOT* Warfare
] [Thread Prev