Next message: David.Goodenough@dga.co.uk: "RE: Units of Work"
From: Tim_Ellison@oti.com (Tim Ellison OTT)
To: jvasta@rational.com (Vasta, John)
Cc: ietf-dav-versioning@w3.org (ietf-dav-versioning)
Message-ID: <2000Feb24.110739.1250.1487452@otismtp.ott.oti.com>
Date: Thu, 24 Feb 2000 11:08:33 -0500
Subject: RE: Enumerating repositories and worksp
spoken quietly:
Actually, I'm in favour of removing repositories from the spec., but then
again I'm not implementing on a repository that requires them.
Tim
----------
>From: Vasta, John
>To: 'jamsden@us.ibm.com'
>Cc: ietf-dav-versioning
>Subject: RE: Enumerating repositories and worksp
>Date: Thursday, February 24, 2000 10:43AM
>
>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
>>
>>
>>
>>
>
>