Next message: Clemm, Geoff: "RE: Units of Work"
From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <8525688F.006E12C6.00@d54mta03.raleigh.ibm.com>
Date: Thu, 24 Feb 2000 15:02:14 -0500
Subject: RE: Enumerating repositories and workspaces
John,
There are also systems that do not require repositories. I think the server
implementation should hide these details and they shouldn't appear in the
protocol. A server can have private initialization and configuration
information for this sort of thing, but the protocol and clients shouldn't
know about it. I also don't see the difference between a server
implementation requirement for a resource to be stored in a particular
place and a policy some Web server administrator dictates. I both cases,
this information will have to be made available to users, but should not be
of any concern to clients. Finally, a server that uses a repository and
requires resources to be stored in a particular place depending on resource
type is free to implement mappings from user URLs to resource locators and
hide them from the client.
In general, WebDAV gives a lot of server flexibility, and servers may
provide WebDAV capabilities with other restrictions. OPTIONS covers some of
this, but not all. It will be difficult if not impossible to specify all
these instances now and capture them in the protocol. So we have to rely on
servers implementing well-defined subsets, and having restrictions that can
be hidden as much as possible. These are discovered by the client
attempting an operation and getting a returned status. It is always
possible for any operation to fail, so clients have to be written to handle
this case anyway.
I know this isn't very satisfying, but I think its the best we can do, and
will probably work OK.
|------------------------+------------------------>
| | "Vasta, John" |
| | <jvasta@Rational.Com>|
| | |
| | 02/24/2000 10:27 AM |
| | |
|------------------------+------------------------>
>------------------------|
| |
| To: |
| Jim |
| Amsden/Raleigh/IBM@IB|
| MUS |
| cc: |
| ietf-dav-versioning@w|
| 3.org |
| 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
>
>
>
>