a) Implement CDDB as is. Everything relevant is free/gpled. Our problem
here is the database. Once we are up and running, we can immediately
offer this as an alternative to Escient. That would answer the
developers need for a current alternative.
b) Start working a new, more inclusive protocol. While the new database
is hopefully populated by hordes of free-lunch-corporate-hating(:))
users, we can calmly sit down and get to the business of protocol
writing. I suppose we should consult with the MP3 people and look around
for other similar efforts. In the end, an RFC would be a good result.
c) Once we have a draft for a new protocol, set up a server to answer
requests in both the new and the old format. Issue reference
implementations for client code and server code.
d) Mark a date to stop supporting the old protocol. It may be far away
in the future. A year, maybe. But let it be set and let the developers
be warned.
Does it sound good enough?
Paulo
> -----Original Message-----
> From: owner-freecddb-developer nospam at bigred.lcs.mit.edu
> [mailto:owner-freecddb-developer nospam at bigred.lcs.mit.edu]On Behalf Of Mike
> Oliphant
> Sent: Tuesday, March 09, 1999 5:38 PM
> To: cdindex nospam at freeamp.org; freecddb-developer nospam at bigred.lcs.mit.edu
> Subject: Ok
>
>
> Ok, I'll back off on my initial opposition to XML. I can see the
> extensibility argument. As a user/cd-player-author, I just
> want to insure
> that cd-lookup is a quick. low-bandwidth operation.
>
> It seems as though everybody has great plans for a new format. This is
> good, but what we really need is a practical, easily implementable,
> more-or-less CDDB compatible system (at least at the server
> end), and we
> need it soon.
>
> We need a system that will allow us to get disc title/artist/track
> information from some form of ID quickly and easily. Idealy,
> it will also
> allow us to add additional information as time goes on.
>
> I'll support such a format in my applications (Grip/GCD) if,
> and when, it
> emerges.
>
>
> Mike
>
>
>
>