Re: WeDAV Versioning Summary
jamsden@us.ibm.com
Mon, 19 Apr 1999 07:18:50 -0400
From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <85256758.003E9569.00@d54mta03.raleigh.ibm.com>
Date: Mon, 19 Apr 1999 07:18:50 -0400
Subject: Re: WeDAV Versioning Summary
>>
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.
</jra>
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.
<<
But this doesn't work. Two users could checkout the same revision in the
same workspace without an activity and not even know it. I think it is the
client's responsibility to reuse "checkout tokens" as workspaces. 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.