Submitting the all the fields in "plaintext", rather than hashing them up on
the client side gives a lot more flexibility. Don't forget that initially we
will be querying a database where the initial data will be based on an old
cut of CDDB, so passing our MD5 hash in will be useless unless we can
convert it to a CDDB hash
The way I see it, the query could go something like this:
1. The client gets all the relavent information fomr the CD, packages it
into an object (C struct/XML/whatever) and fires it off to the server.
2. The server performs some form of hash on the object. If anything matches,
it returns a list of the matching items to the client.
3. If nothing matched, we re-hash the object using the old CDDB hashing
method, and see if we have any matches from the data loaded from the old cut
of CDDB. If anything matches, we return it to the user.
4. If we still have nothing, then we have the option of doing some fuzzy
matching - "SELECT * WHERE LENGTH(track1) is_nearly nospam at track1length" - or
returning not found to the client.
This would give several advantages.
1. We don't have to convert all the old hashes from the old CDDB cut to the
new format. They can co-exist side by side.
3. Fuzzy matching is possible without needing to resbumit the data, wheras
it's not really doable if we only have an MD5 hash to work with.
4. KISS!
Bandwidth isn't an issue for passing the object - 1 byte for number of
tracks, plus 20 words (1 for each track length, in seconds). AFAIK there's
not much more we can tell about a CD when it's first inserted.
The trick is passing enough data in so we can use our new, all singing all
dancing hash function if we want to, but if not we can still use the old
CDDB hashing function.
Cheers... Mike