W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 1996

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

From: Christopher Seiwald <seiwald@perforce.com>
Date: Tue, 3 Sep 1996 16:38:20 -0700
Message-Id: <199609032338.QAA04312@spice.perforce.com>
To: w3c-dist-auth@w3.org, www-vers-wg@ics.uci.edu
| 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:


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.

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.

Received on Thursday, 5 September 1996 12:34:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:08 UTC