Re: Seiwald Q & A -- "GET for EDIT" cookies
Christopher Seiwald (seiwald@perforce.com)
Tue, 3 Sep 1996 16:38:20 -0700
| From: "Roy T. Fielding" <fielding@liege.ICS.UCI.EDU>
|
| > Now Roy Fielding says that Content-Version is opaque and could
| > be used exactly for this purpose, 'cause no one would be the wiser
| > if the Content-Version were different for each checkout of the
| > same document. This is true, but now the names of these fields
| > are losing their meaning, no? If it's checkout context, call it
| > "Checkout-Context" (or "Checkout-Cookie").
|
| Checkout does not have meaning on all systems, whereas version has a generic
| meaning (at times, too generic). It is intended to be as flexible as possible.
| The "Content-" prefix is a requirement of MIME for what HTTP calls
| entity-header field names.
Not to beat a dead horse (but this one's still kicking):
I'm pushing for us to recognise "checkout" as a meaningful act for the
version abstraction we are trying to support, whether or not the underlying
system can make real use of it. It means "GET the SOURCE for EDIT".
"GET" because the document has to be fetched (or via existing methods
determined that the user has the requested copy), "the SOURCE" because
the user needs the document as it is prior to any server-side
interpretation, and "for EDIT" so that the VC backend is aware of the
user's activity.
All VC systems can cook up a checkout cookie; some VC system will have
difficulty without one. The simpler systems - RCS, SCCS, and CVS may
well be wrapped with some layer that provides the context.
Here's how I see them being used, again with Perforce thrown into the
mix because it has fairly modern VC semantics:
CHECKOUT LOCK CHECKIN
----------------------------------------------------------------------------
RCS Probably just Verifies that Verifies
SCCS emits URL+version, the cookie that cookie
so that the represents represents
subsequent the head rev. LOCKed rev.
LOCK or SUBMIT May be a no-op
can make sure user if the SCCS/RCS
has the head rev. wrapper does
May imply LOCK, LOCK on CHECKOUT.
since RCS/SCCS don't
normally support
unlocked checkout.
CVS Emits the line Throws up its Verifies
from the CVS/Entries hands because that cookie
file that reflects CVS doesn't represents
the file+rev being support locking. head rev.
edited.
ClearCase Emits view-extended Verifies that Verifies
pathname and rev of cookie represents that cookie
file being checked out. checked-out file represents
Because of CC's auto- and does a CC LOCKed rev.
branching, the rev may reserved checkout.
be different that what
was requested.
Perforce Emits client pathname Verifies that Verfies
and rev of file cookie represents that cookie
being checked out. checked out file. represents
head rev.
There is use for the checkout cookie for all these systems, even if the
cookied degrades into being little more than "Content-Version". Since
All VC systems can make use of the cookies, and some need them for sane
operation (checkin without checkout under clearcase is a no-go), it makes
sense to use a single tag across all underlying VC systems.
IMHO, of course.
Christopher