Re: Seiwald Q & A -- "GET for EDIT" cookies
Christopher Seiwald (seiwald@perforce.com)
Wed, 28 Aug 1996 22:00:22 -0700
I'll try to explain the notion behind "GET for EDIT" cookies a little
since both Jim and David's responses showed that my initial explanation
left a bit to be desired.
Me:
| >>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.
| >
Jim:
| >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).
David:
| 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.
Me again:
Locking ("reservations") can be handled by LOCK, I quite agree. But
SCM systems don't hang all their context on a lock: they hang it on the
"checkout". That's when the user tells the system, "I'll be changing
this here document," and the system records that fact for the day when
the user says, "Uh, here's that document I changed." The SCM system uses
this context to keep track of the dozens (thousands?) of users out there,
all trying to change the same set of documents (but invariable all
starting with different revisions of those documents).
Not all SCM systems require a lock before checking in documents, and
some acquire that lock automatically, so many PUTs are likely to happen
in the absense of a LOCK. But _all_ SCM systems (except CVS) require
some sort of checkout (locking or non-locking) before checkin. Now you
could fudge it, and by remembering the URL and revision do a paired
checkout/checkin to establish the required context. But this defeats
a feature that all modern SCM systems boast: tracking user activity.
They have this feature because users don't remember what they're doing,
and they certainly don't remember what other people are doing. Half
the job of SCM systems (and by extension, version aware web servers) is
to keep track of who is doing what to what, just to remind everyone
involved. Those scenarios I cooked up (where Joe and Jane keep stepping
on each other) weren't just from my past experience: they were from my
past week's experience.
Only one user can LOCK a file. If the context is established on LOCK
then there will be only one context per document, precluding Joe and
Jane from finding out that they're doctoring the same text.
Normally SCM systems have a tight association between the checkout
context and the checked-out file, because often there is no way to work
"outside" of the SCM system. But if the SCM system is the backend of
a version-aware web server, with the actual work happening in "stateless"
web clients, then that context must be represented by a cookie.
The cookie belongs to the underlying SCM system; whether it is an MD5
hash of the document contents, some cryptic string churned up from bowels
of the SCM database, or "allworkandnoplaymakesjohnnyadullboy" is not
HTTP's or a Web authoring tool's business. They just have to keep it
associated with the checked-out document so that it can be reunited with
the checkout context at checkin time.
This cookie is the single most important component of distributed web
authoring, IMHO.
Christopher
----
Christopher Seiwald Perforce Software www.perforce.com
seiwald@perforce.com f-f-f-fast SCM 1-510-865-8720