Good point. I would suggest that this is an implementation issue for the
client, allowing for local mods to DB entries. As a user, I'd rather
modify 1 in 1000 that was somehow screwed up by mob rule than the current
state where it seems that 1 of 10 CDDB entries has a mistake. I'm
suggesting the "lots of eyes find lots of bugs" paradigm be applied to the
entries.
>> I continue to suggest we should use a simple majority rules to determine
>> the correctness. Justin did say:
>
>Majority rules. How do you know if there are duplicate votes. You need
>the hash.
Agreed. Good plan.
>> How would this fit into the DNS-based system (which is appearing to be the
>> most technically sound and efficient distributed solution thus far)?
>
>DNS or WWW is just a feed to the client, Im not suggesting its used for
>data collection and input
In order for the "many eyes" approach to work on these entries, we'd need
to keep track of the various unique submissions for a disc and tally
submissions for each. It seems that this would have to be stored in the DB
somehow. Is this simply going to be too complex? I can easily picture it
from a RDBMS perspective (my primary background) but am having difficulty
seeing how the DNS scheme would accomodate such a thing. If it can, good
and I'll wrtie some code. If not, I would simply defer because I really
like the DNS idea.
-----
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