Next message: Vasta, John: "RE: Enumerating repositories and workspa"
From: Tim_Ellison@oti.com (Tim Ellison OTT)
To: ietf-dav-versioning@w3.org ('Delta V')
Message-ID: <2000Feb23.100700.1250.1485694@otismtp.ott.oti.com>
Date: Wed, 23 Feb 2000 10:11:08 -0500
Subject: Re: Enumerating repositories and workspa
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.
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.
Similarly for workspace ownership. Adding workspace ownership is a
convention that you might choose to adopt as a working style by your
clients, but as far as the protocol is concerned, if workspaces had owners
why not other types of resource?
I'll be interested to see other people's comments.
Tim
----------
From: Vasta, John
To: ietf-dav-versioning
Subject: Enumerating repositories and workspaces
Date: Tuesday, February 22, 2000 12:02PM
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?
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.
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.)
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.)
John Vasta
Rational Software