$ This is an interesting way to go. You could probably use a similar
$ approach with gopher. HTTP might provide more features, though, in the use
$ of MIME headers for carrying some of the details.
Indeed. My demo was, as I'm sure you can tell, hacked up in a couple
of hours. FWIW, the intention was to demonstrate that a form of URN
lookup is perfectly feasible within the confines of the WWW software,
not to provide a complete implementation!
If we're talking about building in client support, I think HTTP would
be the best place for this info - servers could have built-in support
for converting templates into suitable multipart MIME messages, and
clients would say
1) Do DNS lookup on the location component of the URN
2) Pick one of the results according to a sensible algorithm
e.g. xarchie style domain weightings and DNS preference values
3) Send the resource identifier portion of the URN to
the chosen server
4) Display a suitably rendered version of the response
Don't forget that URNs could be deployed in the meantime, using some
variation on the scheme I outlined! :-)
$ My question would be, is this going to scale? And, is this better than
$ using whois++, which is designed to scale? Martin, didn't I recall you had
$ a prototype whois++ server? Any chance of running a whois++ server
$ side-by-side for comparisons?
I think it depends what context you have in mind when you ask about
scaling - DNS? Template contents? There would only be a small
number of extra DNS entries (of the order of one per publisher? :-)
and templates would be cached using the mechanisms currently being
developed for WWW in general. How about that?
Martin