Re: Stab in the dark
hoymand@joe.uwex.edu (Dirk Herr-Hoyman)
Errors-To: listmaster@www0.cern.ch
Date: Thu, 17 Mar 1994 17:35:51 --100
Message-id: <9403171627.AA16997@joe.uwex.edu>
Errors-To: listmaster@www0.cern.ch
Reply-To: hoymand@joe.uwex.edu
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: hoymand@joe.uwex.edu (Dirk Herr-Hoyman)
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: Stab in the dark
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Length: 1511
At 11:06 AM 3/17/94 +0000, Jon P. Knight wrote:
>On Thu, 17 Mar 1994, Keith Moore wrote:
>> > Then
>> > the rest of the URN is appended - in the example this gives us
>> >
>> > http://www.mrrl.lut.ac.uk/urn/martin/top
>>
>> Yikes!! I see no reason that a URN should be constrained to contain
>> any part of an eventual URL (or likewise, why a URL should have to
>> contain any part of any of the URNs that might point to it.)
>> And I can see some very good reasons NOT to impose this constraint.
>>
>
>Martin showed me this last night and I was under the impression that the
>URL <http://www.mrrl.lut.ac.uk/urn/martin/top> wasn't an eventual URL that
>the URN was pointing at but was the URL of the URC which contained
>multiple URLs which you then followed to get to the resource. I can't
>really see why the system couldn't tack more or less anything from the end
>of the URN onto the URL stem returned from the DNS to point to the URC; surely
>this would be up to the administrators of that URC to decide? What's the
>good reasons that this won't work?
>
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.
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?