Using DNS examples

robin nospam at acm.org
Wed, 10 Mar 1999 18:41:32 GMT

On Wed, 10 Mar 1999 09:05:01 -0800 "Justin R. Erenkrantz"
<justin nospam at erenkrantz.com> wrote:
> Isn't the point if that we use DNS, we have a standard system - no coding
> involved for server or communication. The emphasis is on the client to
> handle the data. However, Jason made the point about how do we keep track
> of DB collisions?

The DNS proposal doesn't itself have to deal with database collisions
since it is always returning information based on a unique key. DNS just
answers queries---it doesn't handle submissions or database distribution
(except in the sense of distributing the ability to answer certain
queries). Collisions are a problem for the mechanism which primes the
DNS tables.

I think this is a really elegant part of the proposal so far. How about
some examples? First a new client which is willing to do lots of
complicated stuff. Then a client which knows about cddb and just wants
easy porting.

The clever client can work out the new cdin-hash and look up:
[CDIN-HASH].hash-to-key.cdin.org
If it wants to reduce the likelyhood of hash collisions, it can ask for:
[THE-WHOLE-TOC].toc-to-key.cdin.org
In either case, it gets back one or more keys representing the possible
matching CDs. There is very likely to be only a single key using
the WHOLE-TOC lookup. This key links to what people have said about
this disk. The client asks for:
[CDIN-KEY].key-to-subs.cdin.org
gets back a list of keys for all the submissions ever made about this
disk (sub-key), including discredited or obsolete ones. Now the client
can ask about each submission individually:
[SUB-KEY].sub-to-xml.cdin.org
gets all the data as an XML record, or
[SUB-KEY].sub-to-relationaldb.cdin.org
gets the list of other keys associated with this CD; these would be
atomic data or keys to albums, pieces, tracks, people etc., each of
which could be the subject of further queries. For cddb compatibility,
the client can ask for:
[SUB-KEY].sub-to-cddbinfo.cdin.org
and get back the existing simple format (with the extended data
wrapped in to the EXT fields where possible).

If someone wants to maintain a best-submission selection mechanism,
they can offer a service to map a cdin-keys to a single sub-key:
[CDIN-KEY].key-to-bestsub.myfavouritemoderator.org
The main servers could offer this too, since clients can always get
at all the submissions and make their own judgement instead of trusting
the central management.

Now to the ther extreme. A simple client which started life as a
cddb-aware application doesn't have to jump in at the deep end. All it
has to do is compute the old cddb-hash and ask for:
[CDDB-HASH].cddbhash-to-cddbinfo.cdin.org
The result looks just like the traditional cddb entry. The mechanism
for loading the DNS has precomputed the best submission(s) to return,
either by human intervention or some automatic scoring.

Of course, all the DNS queries could be equally well handled by a
gateway which maps http://www.cdin.org/cdin/TYPE-OF-QUERY/[KEY] to
[KEY].TYPE-OF-QUERY.cdin.org

Robin.

-- 
R.M.O'Leary <robin nospam at acm.org> +44 7010 7070 44, PO Box 20, Swansea SA2 8YB, UK