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

Talking about dead horses... When people say things like "Check Out the
Source" I get worried. As I mentioned previously there are cases where
the number of links between the final version of an entity and the
original version contains many nodes. Rather than trying to put together
a "GET for Edit" which will either only have one level and thus is not
very useful or will hack the hell out itself to support more levels we
should just support links which solve the problem very elegantly.

					Yaron

>----------
>From: 	Christopher Seiwald[SMTP:seiwald@perforce.com]
>Sent: 	Tuesday, September 03, 1996 4:38 PM
>To: 	w3c-dist-auth@w3.org; www-vers-wg@ics.UCI.EDU
>Subject: 	Re: Seiwald Q & A -- "GET for EDIT" cookies
>
>| 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
>
>

Received on Thursday, 5 September 1996 12:49:11 UTC