Next message: Vasta, John: "RE: Enumerating repositories and worksp"
From: Tim_Ellison@oti.com (Tim Ellison OTT)
To: jvasta@Rational.Com (Vasta, John)
Cc: ietf-dav-versioning@w3.org ('Delta V')
Message-ID: <2000Feb23.120818.1250.1485931@otismtp.ott.oti.com>
Date: Wed, 23 Feb 2000 12:08:51 -0500
Subject: Re: Enumerating repositories and worksp
<tim>
The principle adopted so far has been that workspaces, repositories, etc.
are just resources, and can be managed in the URL namespace however the
client chooses. The server is free to restrict the areas where these
resources are stored, but there is no 'meta'-area containing such resources.
</tim>
<john>
If the server is free to have restrictions, then how can
clients discover what the restrictions are? I don't see
how clients can do much of anything without knowing
how to form URLs to resources, if there are restrictions
on the form of those URLs.
</john>
You're right. My recollection was that the repository would list these
restrictions (as it does for the location of versioned resources and
BIND-able resources).
<tim>
As such there is no way for clients to discover all workspaces any more than
there is a way to discover all activities or configurations, etc. It is
unclear to me that the client should be shown all possible repositories in a
browser.
</tim>
<john>
But you can discover all activities, configurations, and
versioned resources in a given repository; there are
special collections defined for them, and a server is
allowed to restrict those resources to be contained in
those collections.
</john>
There are?! Why?
<john>
If a client cannot discover what the repositories are,
how can it specify the location of any of the resources
which are in those constrained areas?
</john>
Agreed. We should either specify eveything, then the client is 'routed' to
the right place to do their stuff, or we specify nothing and anarchy applies
(i.e., all resources are equal and clients decide where things will be
stored).
Tim