RE: Seiwald Q & A -- "GET for EDIT" cookies
Yaron Goland (yarong@microsoft.com)
Tue, 3 Sep 1996 19:10:37 -0700
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
>
>