Next message: Clemm, Geoff: "RE: Units of Work"
Message-ID: <65B141FB11CCD211825700A0C9D609BC01879989@chef.lex.rational.com>
From: "Vasta, John" <jvasta@Rational.Com>
To: "'jamsden@us.ibm.com'" <jamsden@us.ibm.com>
Cc: ietf-dav-versioning@w3.org
Date: Thu, 24 Feb 2000 10:27:14 -0500
Subject: RE: Enumerating repositories and workspaces
Jim,
This isn't the same problem I was trying to describe. I'm talking about the
problem that developers of DAV clients will have trying to create software
which will interoperate both with servers that have constraints on resource
locations, and servers which don't. I am not talking about the user of those
clients.
The current draft Delta-V document allows for servers to have constraints,
because real versioning systems in existence today do, and it would not be
possible to implement the protocol on top of those systems (at least, not
efficiently) unless the protocol models those constraints. When you wrote "I
think there shouldn't be any repository", do you really mean that you
advocate removing all the repository language in the current draft? Since I
hadn't seen any comments like that before, I assumed the repository part of
the draft was generally accepted by everyone. Without it, I'm at a loss as
to how to implement the protocol on top of systems for which repositories
are a fundamental feature of their architectures.
John
> -----Original Message-----
> From: jamsden@us.ibm.com [mailto:jamsden@us.ibm.com]
> Sent: Wednesday, February 23, 2000 3:07 PM
> To: ietf-dav-versioning@w3.org
> 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
>
>
>
>