Re: WeDAV Versioning Summary

Geoffrey M. Clemm (gclemm@tantalum.atria.com)
Mon, 19 Apr 1999 13:17:57 -0400 

Date: Mon, 19 Apr 1999 13:17:57 -0400
Message-Id: <9904191717.AA25128@tantalum>
From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: jamsden@us.ibm.com
Cc: ietf-dav-versioning@w3.org
In-Reply-To: <85256758.00546CC4.00@d54mta03.raleigh.ibm.com>
Subject: Re: WeDAV Versioning Summary

   From: jamsden@us.ibm.com

   I don't think servers should make any constraints on what resources a
   client can or cannot create other than the usual denial of service
   resulting from resource constraints.

There probably are a variety of reasons why a server might constrain
what resources a client can create (locking and access control come
to mind), but I'm not sure how this is relevant to the question of
whether a server be required to introduce a different workspace in
response to every "workspace-free" checkout request.

   Servers should not reuse workspaces on
   any client's behalf because that would have unexpected user-level semantic
   consequences.

I'd have to see one of those unexpected user-level consequences, and
be convinced they are important.  Until then, requiring a server to
*not* re-use a workspace for checking out a different resource remains
a gratuitous restriction that significantly hampers my ability to
efficiently implement a cheap "workspace-free" checkout request.

   If there is an efficiency problem, servers are free to do all
   sorts of special things with workspaces (or any other resource) that don't
   have properties or content.  It seems like an empty workspace would be a
   pretty simple thing to optimize.

I only need to do one special thing; namely, to reuse the workspace
when I know it is safe to do so.  And things that are pretty simple
to do in isolation can be surprisingly complicated to do in the
context of an existing system.

   I also think we should make it clear that
   clients should be responsible for reusing workspace "checkout tokens" in
   reasonable ways corresponding to the work they are doing.

A client that is implementing its own workspace should not be expected
to be concerned about "reusing checkout tokens".  That's just a concern
for a server that is trying to support such a client.

   This issue is why I didn't want to introduce checkout tokens. This little
   bit of flexibility for servers moves a lot of responsibility to clients
   that most will not be prepared to do. It also limits sharing between
   clients because the checkout tokens are too private in nature.

In our discussions, it was made clear that at least one important
client vendor was planning on providing lots of clients that will take
on the responsibility of workspace management, and did not want to do
workspace-token re-use management at the same time.  It was also made
clear that our server vendors were interested in a protocol that
provided inteoperability with those clients.

So the central question remains, what are the negative consequence of
simply saying "a checkout produces a new working resource", and leave
the decision of whether a workspace-free checkout request can re-use
an existing workspace, up to the server.

Cheers,
Geoff