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

[Scott Wheeler <wheeler kde org>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 02 March 2004 5:37, Colin Walters wrote:
> 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?

Well, that's risky as Apple *could* always turn up with a patent for the 
protocol.  If we could somehow get Apple into the loop and if they're 
interested in publishing the format and granting a royalty free license then 
I think this would be great.  I don't know how much to expect of them on this 
matter however.

> > 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.

Well, really I don't have any idea what we're talking about.  :-)  I've only 
used iTunes once in my life and then not on a LAN, so forgive me if I'm 
missing the finer points here.  I've been told that it has something like 
"stream what I'm playing over the LAN" or something like that, and I assumed 
that it was something like that which we've been talking about.  (In fact 
Aaron was the one that I think mentioned this to me, which is how he ended up 
on CC.)

But now it seems like we're discussing file based rather than stream based 
sharing...  Maybe it would be best if we could back up a bit and someone 
could explain the goal of this lib in non-iTunes terms (i.e. "iTunes Shares" 
doesn't really mean anything to me).

> 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.

Well, I don't think it's a fundamentally bad idea since presumably these LANs 
will be fairly constrained, but since at first it just makes things more 
complicated I would leave it as an interesting toy for later.

> > 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.

Same here.

- -Scott

- -- 
If you want to get laid, go to college, but if you want an education, go to 
the library.
- --Frank Zappa
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQFARF/AQu0ByfY5QTkRAqhVAJ4w/osaIh2Cf39NygzctRHVRon50QCfYELl
0Mz0tD3A30Y6zYtkmOofk1I=
=DStq
-----END PGP SIGNATURE-----