Re: WeDAV Versioning Summary

jamsden@us.ibm.com
Mon, 19 Apr 1999 11:20:45 -0400 

From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <85256758.00546CC4.00@d54mta03.raleigh.ibm.com>
Date: Mon, 19 Apr 1999 11:20:45 -0400
Subject: Re: WeDAV Versioning Summary



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. Servers should not reuse workspaces on
any client's behalf because that would have unexpected user-level semantic
consequences. 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 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.

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.




"Geoffrey M. Clemm" <gclemm@tantalum.atria.com> on 04/19/99 11:09:58 AM

To:   Jim Amsden/Raleigh/IBM
cc:   ietf-dav-versioning@w3.org

Subject:  Re: WeDAV Versioning Summary





The purpose of the "workspace as checkout-token" was to allow
interoperability between servers that require a heavy-weight
server-side workspace for a checkout and clients that want to do their
own workspace management.  It is prohibitively expensive for such a
server to allocate a new workspace for every checkout.

A solution to the problem is for such a server to allocate a small
"pool" of workspaces used for checkouts with no specified workspace.
When the server gets such a checkout request, it picks the first
workspace in the pool that doesn't have that resource checked out (a
cheap operation), and uses that workspace for the checkout.

To make this solution feasible, it is sufficient for the model to say
"each CHECKOUT produces a new working-resource", and *not* say
"each CHECKOUT produces a new workspace".

I'd go even further, and provide an "implementation note" that
describes the above solution as a reasonable way for a "heavyweight
workspace" server to implement the protocol.

Cheers,
Geoff

   From: jamsden@us.ibm.com

      <gmc> The server is allowed to use an existing workspace instead
      of creating a new workspace, so this should probably be "the server
      allocates a workspace for the checkout, possibly reusing an existing
      one, and returns this workspace as a `checkout token' for use by the
      client to identify the working resource."

      <jra>
      I dont' think this is the case. Only users can reuse workspaces
      (tokens or
      not) because reusing a workspace implies being able to see working
      revisions checked out in that workspace. You wouldn't want a server
      automatically making someone else's checkouts visible to you.


   <gmc>
   I believe this *must* be the case to achieve interoperability between
   a "token-based" client and a "workspace-based" server.  A workspace on
   a workspace-based server is far too expensive for it to have to create
   a new one on every checkout.  Since a token-based client will only use
   that "workspace" to access the single URL that it checked-out, this
   shouldn't be a problem.  Also, the "lock" that a token-based client
   will commonly put on the working resource will ensure that the working
   resource is not modified by another client.  So the fact that other
   clients may have checkouts in that workspace would not be a problem.

   <jra>
   But this doesn't work. Two users could checkout the same revision in the
   same workspace without an activity and not even know it.

Remember that in these checkouts, the *server* decides which workspace
to use, so it would just not choose a workspace from its pool that already
has a checkout for that resource.

   I think it is the
   client's responsibility to reuse "checkout tokens" as workspaces.

We are trying to handle the case where the client is *not* taking on
this responsibility.

   This
   seems to be what Chris wanted, client supported version namespace
   management rather than server supported. Given the flexibility implies
   handling the responsibility to do something with it.

Yes, Chris wanted clients to not have to take on the responsibility of
workspace re-use.  So we just have to design the protocol to allow
interoperation between clients that do not want this responsibility,
and servers that only support heavyweight workspaces.

Cheers,
Geoff