Next message: Clemm, Geoff: "RE: Labels"
From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <8525688E.006E8705.00@d54mta03.raleigh.ibm.com>
Date: Wed, 23 Feb 2000 15:07:12 -0500
Subject: Re: Enumerating repositories and workspaces
John,
Responses below in <jra> tags.
|------------------------+------------------------>
| | "Vasta, John" |
| | <jvasta@rational.com>|
| | Sent by: |
| | ietf-dav-versioning-r|
| | equest@w3.org |
| | |
| | 02/22/2000 11:41 AM |
| | |
|------------------------+------------------------>
>------------------------|
| |
| To: |
| ietf-dav-versioning@w|
| 3.org |
| cc: |
| Subject: |
| Enumerating |
| repositories and |
| workspaces |
>------------------------|
There seems to be no way for a client to discover all the repositories and
workspaces known to a server. I think a client interface would need this
capability in order to support these kinds of use cases:
1. A user wants to edit a resource, or add a new resource. The client
interface would like to provide a file browser kind of view for the user to
select a resource to work on, or a location to work in. If the server
constrains resources to be contained in repositories, how does the client
discover what all the possible repositories are?
<jra>
This is a general problem. If a user wants to edit a resource that does X,
how does he know where it is? The answer is someone tells him the
organization of the Web project, and he browses the collection hierarchy
with that knowledge to find the desired resource. Just like we all use file
systems. Putting one resource type in a special place only invites the
desire to put any other resource type in some special known place, and
we're right back where we started. The only reason WebDAV should specify
anything is if the information is required for its own use, or if there is
some interoperability opportunity that would be lost without it. We've
intentionally tried to avoid casting policy decisions into the protocol in
favor of mechanisms that can support many policies. Interoperability
happens at the mechanism, not the policy. If policies become popular in
their own right, clients may be developed to expect them. This could
introduce an interoperability problem, but attempting to determine all
possible policies that should be supported is a much greater problem.
</jra>
2. A user is working on multiple projects, each in its own workspace. When
starting a client authoring tool, the tool will want to ask the user which
workspace to work in. In this case, not only does it seem desirable to
enumerate the workspaces known to the server, but also to identify which
workspaces "belong" to a particular user.
<jra>
Same problem as above. A user would be expected to know something about the
project they are working on, like the overall structure of the Web
application, resource naming conventions, HTML styles, etc. Included in
this would be location of project information and reusable or shared
workspace. I don't think the protocol should be concerned with any of this.
</jra>
I think there should be two properties which identify collections that
contain repositories and workspaces. The properties could be defined on the
root of a server's URL namespace, or on every resource. (Alternatively, a
server could make all workspaces and repositories appear under the root of
its namespace; a versioning client could use the resourcetype property to
distinguish them, but downlevel clients wouldn't, and so would present a
confusing view of resources to a user.)
<jra>
I think there shouldn't be any repository, and that workspaces are user
objects that can be placed anywhere in the namespace the user wants.
Otherwise we get undesirable coupling between independent projects and
workspace name collisions.
</jra>
Also, I think workspaces should have an "owner" property so that clients
can
identify candidate workspaces for selection by a user. (The DAV:owner
element defined for locks could be used for this property.)
<jra>
Workspaces are resources, and can have ACLs to control access. Otherwise,
they are not "owned" by anyone and can be shared by many users at the same
time. We don't think this will be the usual use case, but there's no reason
to prevent it unless that is some development organization's policy.
</jra>
John Vasta
Rational Software