Re: [Rhythmbox-devel] Re: Functional DAAP client code

Hi there,

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 
> 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:
>> 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:
>>> 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
>>> Version: GnuPG v1.0.7 (GNU/Linux)
>>> iD8DBQFAQymxQu0ByfY5QTkRAuYKAJ4uQgvevxv3E9Ix/S+Y2g5aO97rUgCdG7Gz
>>> kOm8mNr8vUOqMPVhrslurUY=
>>> =xeT8
>>> -----END PGP SIGNATURE-----
>> --
>> David Hammerton
>> Welfare *NOT* Warfare
>> _______________________________________________
>> rhythmbox-devel mailing list
David Hammerton
Welfare *NOT* Warfare

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]