Re: URLs for trees.

hallam@dxal18.cern.ch
Thu, 15 Sep 94 18:10:54 +0200


>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.