> (1) Extensible. This is one of the biggest problems with CDDB. For
> those of you who weren't on the list before, I'd like a format that
> supports album-oriented and multi-track oriented music.
Extensible statically (compile-time) or dynamically (server sends metadata)?
If we make it dynamically extensible (something along XML - although I'm not
big into XML), we then have to code up a metadata (i.e. field
specifications) and such. Not a bad idea though. Might be worth the
effort. Any ideas here? Might have version numbers associated with our
formats. We define a version number and have a certain metadata associated
with the communication. If or when the version is updated, the client
retrieves the new metadata from the server and goes along its merry
business. Allows for changing of data (the removal of the leadout with
CDIndex) with minimal hassles to the client.
> (2) Backwards compatible with CDDB. This has been discussed a lot,
> and it comes down to the fact that developers need to be able to
> switch to the new servers without writing any code. This is very
> important. They can switch to the new format once they see the
> advantage, but in the meantime we MUST redirect the flow of
> information from Escient's servers to our own.
So, the server must understand and spit out CDDB as well as our new format.
Might cause some clunkiness. What could be a really cool idea is to have a
separate CDDB server that queries the other server in realtime (i.e. as a
client) and passes the results along in CDDB format (faster speed? query
directly to OUR system). That way we don't have to deal with two separate
code bases talking to the actual files. But, it might require two initial
pieces of software (CDDB->new server ONLY, and the new server), but it makes
a bit more sense - if CDDB dies out, we just discontinue those servers.
Might make it less complicated in the long run... Food for thought!
> (3) Free. Need I say more? ;-)
Wouldn't have it any other way...
Later,
Justin