[5620] in www-talk@info.cern.ch
Re: URLs for trees.
daemon@ATHENA.MIT.EDU (hallam@dxal18.cern.ch)
Thu Sep 15 13:51:29 1994
Date: Thu, 15 Sep 1994 19:37:51 +0200
Errors-To: listmaster@www0.cern.ch
Errors-To: listmaster@www0.cern.ch
Reply-To: hallam@dxal18.cern.ch
From: hallam@dxal18.cern.ch
To: Multiple recipients of list <www-talk@www0.cern.ch>
>EHr, no, but you need a new browser to handle the multi-part messages
>anyway, and as you said this isn't likely to be used directly by
>browsers but by other applications. So I don't see why mehtods would
>introduce a problem.
We were thinking about modifying the server in any case to give a recursive
directory list. That does not require modifications.
Latest suggestion (author requested anonymity):-
/...
1) Its clean
2) Only backwards bongo is that anyone calling a directory ... will screw
things.
3) It gets round semantic problems with *
4) ITS COMPATIBLE WITH VMS !!!!
>Groan, just as they finalised the draft :-)
Well the draft is hardly complete in any case. There are no URLs for posting
news. And the gopher URL sucks turkey eggs.
>I suppose it depends how you think about this facility. Are we talking
>about a "meta object" (URL), or about an operation (method)? As we're
>talking about protocol here I think the latter is more appropriate.
No we are talking about an operation.
fred/... is a directory listing (no client update, server update)
fred/.../* is a compound object (lots of new software)
OK I may accept that MGET should be required for fred/.../* but for fred/...
we are talking GET because only one object will be reteurnethed unto the
client.
Phill.
