Re: Seiwald Q & A

At 3:17 PM 8/27/96, Jim Whitehead wrote:
>Christopher Seiwald sent me some interesting questions this morning, and I
>thought I would share the Q & A.
>>1.  A fundamental component of "GET for EDIT" has to be a cookie that
>>represents any stored context in the document server that needs to be
>>reunited with the document on checkin.  Most, if not all, SCM systems
>>are aware of their users' activity and use this awareness to keep users
>>from stomping on each other's work.
>
>I think that use of cookies might be necessary in an implementation.
>However, I suspect that you can maybe do it all with only MD5
>authentication (i.e., only knowing the user).
I'm not sure of the role for the cookie in this (just call me dense (later
on in this mail I guess why you might use one)). But the reservation and
context establishment should be handled by LOCK. If a server requires
special reservation for editing, it's the client's responsibility to obtain
a lock on the file before doing a PUT. If the client already has a cached
copy, a "conditional GET" based on the version at the server might be
useful.

I think decoupling the access control aspects (LOCKing and so forth) from
the GET/PUT operations gives us a lot more generality, extremely easily. I
don't see any situation where "get for edit" is really different from "LOCK
resource for writing" followed by GET. If the client has a local copy, the
GET could even be conditional on the version they have being a leaf (though
this would not be a requirement). Then we might even be able to PUT a few
times before releasing the lock!

Attempts to PUT without a needed lock could bounce on servers that need or
want to enforce such a discipline on their clients.

>
>>2.  "GET for EDIT" also, mind you, has to be able to GET something other
>>than the head ("tip") revision of the document.  Not everybody wants to
>>start their edits with the most current rev.  And I assume we both agree
>>that "GET for EDIT" means get the source, not any derived version.
>
>Absolutely.  GET for EDIT would apply to an entity, and a versioned
>resource would contain many entities, one for each version.

In the requirements, since "GET for edit" is the same as GET, this is a given.

>>3.  MkDir is nonsensical, since directories are artifacts of filesystems,
>>and the URL namespace is not a filesystem!  I say if you PUT the blinkin
>>document somewhere, the directory gets created if that's what the server
>>needs.
>
>Well, I've been very careful to couch my discussion in terms of hierarchy
>levels, since I know that a filesystem mapping is only one possible name
>space mapping for the URL namespace for a server.
>
>That acknowledged, I think a PUT that automatically creates hierarchy
>levels is not a great idea, since a user who mistypes the name of a level
>could inadvertently create a new hierarchy level, when they really would
>have preferred an error message, and been forced to re-enter the name.

Now we get into Yaron's requirements (about which I can only comment in
general terms. However I'll note that a lot of the file-management
operations (DELETE, COPY, MKDIR) seem to me to be out of scope of
Versioning (and maybe even collaborative editing). I also don't think that
HTTP resources map 1-1 into filesystem objects, and would like to keep the
separation in our standards.

I don't necessarily want to suggest that we rule out these operations, but
they seem to be more general HTTP issues than versioning or authoring
issues to me.

>
>>4.  For new documents, I think rather than a blind, out of the blue PUT
>>there should be something analogous to "GET for EDIT" -- e.g. a "fake GET
>>for ADD".  The primary reason for this is to support item #1 above --
>>to let the document server/SCM system know what the user is up to.
>
>Couldn't cookies handle this?
Can you guys explain the cookies to me? Do we use a hash (like MD5) to
determine if another GET is required, or what? At any rate,as I've said
already a few times, I think that separation of concerns makes "GET for
edit" into a composite operation.

>>5.  Versioning of directories is also non-sensical, for the same reason
>>as #3 above.  Supporting renaming is one thing, but buying into a solution
>>that involves versioned directories is brainocide.
>
>Hmmm.  Well some form of configuration support is definitely necessary.  A
>versioned hierarchy level seemed like a good idea to me, and is backed up
>by real-world use.

Well, Brainocide sounds fun to the researcher in me... But I agree with Jim
(if that's what he really means) that versioned directories belong with
configuration management in the second phase of versioning work: there are
a lot of dissimilar/funky models of this stuff floating around, and we will
need to find a clean compromise. I think this needs to go to the back
burner for the immediate crunch of work.

>>6.  I think locking can be punted.  Add it in the next rev.
>
>Why?  I think there's a better case for locking than for versioning
>capability.  Also, the next rev. is HTTP/NG. I don't think there will be a
>1.3.

Locking is better IMHO than special variants of GET. Let's make the
concerns of access and update completely separate.

I'm trying not to be a partisan for my own point of view, but rather to
find common ground that covers all the versioning scenarios around. But I
will note that my goal is to make locking unnecessary for some kinds of
collaborative update. Now, my research may fail, but separating locking
functionality from GET functionality doesn't hurt the rest of the world,
and lets my kind of apporach fit in with the world.

   Anyway, even systems like CVS try to keep locking to a bare minimum, so
it's not just me...

HTTP has flourished on the basis of incredible simplicity and orthogonality
-- so even though versioning is complex, let's try to preserve these
virtues to the greatest extent that we can...

   -- David

--------------------------------------------+--------------------------
David Durand                  dgd@cs.bu.edu | david@dynamicDiagrams.com
Boston University Computer Science          | Dynamic Diagrams
http://www.cs.bu.edu/students/grads/dgd/    | http://dynamicDiagrams.com/

Received on Wednesday, 28 August 1996 23:21:25 UTC