Re: Submit from the client in plaintext

Jason Dufair (funne nospam at iquest.net)
Tue, 09 Mar 1999 12:03:29 -0500

Just got on the list this morning. I like this. It will make it easy for
folks building clients and even scripting via shells, etc not to have to
mess with MD5. Let's keep the hashing on the server. This way many more
clients can support the new system more quickly.

Also, what about SHA instead of MD5. I understand it's "freer."

At 04:36 PM 3/9/99 -0000, you wrote:
>Folks
>
>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
>
>
>

-----
Jason Dufair
funne nospam at iquest.net
http://www.iquest.net/~funne
http://www.iquest.net/~funne/jdufair.asc for PGP public key.
"A laugh for the newsprint nightmare, a world that never was
Where the questions are all 'why' and the answers are all 'because'"
-Bruce Cockburn