Re: v6: external members

>Roy also wrote:
>
>>With that sense, external members ==> server-side redirects.
>
>which I simply don't get.

I meant that the role of an external member within a namespace is
essentially equivalent to a symbolic link in a filesystem -- it adds
a name to the space that corresponds to some other resource, thus
resulting in a name redirection.  In the filesystem, the standard library
would follow the link on an open, whereas accessing the external member
name on the Web would result in either an internal or external (HTTP)
redirection to the other resource.  This is a common feature allowed
by Apache configuration files.  From WebDAV's perspective, the important
thing is that it allows the client to see what names are already in use,
even if some of those names are merely handles for negotiation points,
gateways, or other non-authorable resources.

I am using the term namespace because it is more neutral to implementation
than directory or index, though I agree that they follow the same purpose.
Tip-toeing on terminology is a side-effect of too many IETF arguments
over the URI technology.  A directory or index is the response we should
get when we ask to look at a namespace.

From a namespace perspective, ordering and duplicate membership is not
allowed.  On the other hand, there are a hundred things that could make
good use of a collection in the generic form of a directed graph.
While I think it is possible to model the namespace using a collection,
I'd absolutely hate for collections as a whole to be hindered by the
restrictions on a namespace.  WebDAV seems to be moving toward the latter
in order to make it easier for implementations; if that is necessary,
I'd rather the result be called something more specific than "collections".

BTW, the reason I think a name change is justified at this point is
because the semantics of MKCOL, etc., no longer correspond to the semantics
they had when we started calling them collections.  This is a case where
continuance of the same names causes more confusion than a discontinuance.

....Roy

Received on Monday, 26 January 1998 22:58:09 UTC