Re: Seiwald Q & A -- "GET for EDIT" cookies

Hi folks,

I have been lurking on this list for while.

I think that I follow Christopher's reasoning here,
and I would like to paraphrase here just to make
sure I have it right...

When a user "checks out" a document for editing,
the revision contrl system "should" record who it
is that is checking out the document so that when
the same user attempts to "check in" the document
there is a mechanism to say "Hey, remember me? I am
checking in the document that I previously checked out
for editing. Here it is." The RCS can verify that it is
the same user that is recorded and proceed, or reject
the action if it is not the same user.

Christopher is asserting that a "cookie" is the best,
if not the only, way to manage the session.

Is that about it?

Murray



At 10:00 PM 28-08-96 -0700, Christopher Seiwald wrote:
>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
>
>
>
Murray Maloney                   "Life is a daring adventure,
Technical Director                or it is nothing" 
SoftQuad Inc                      -- Helen Keller

Received on Friday, 30 August 1996 10:05:25 UTC