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

Under the heading of "ME TOO" the requirements sheet I posted had Check
Outs and Locks clearly separated. They are two totally different
operations.
			Yaron

>----------
>From: 	David G. Durand[SMTP:dgd@cs.bu.edu]
>Sent: 	Tuesday, September 03, 1996 9:07 PM
>To: 	w3c-dist-auth@w3.org; www-vers-wg@ics.UCI.EDU
>Subject: 	Re: Seiwald Q & A -- "GET for EDIT" cookies
>
>At 4:38 PM 9/3/96, Christopher Seiwald wrote:
>>| From: "Roy T. Fielding" <fielding@liege.ICS.UCI.EDU>
>>| 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.
>
>If we have a CHECKOUT method, then we don't need the LOCK method I propose.
>But we must tell clients to ask for a checkout before trying a put, in case
>they need one. We cannot require that clients do a special GET operation
>before posting an update because it's not always required, and could just
>send a lot of redundant bytes. A system is free to implement the protocol
>so that sending the redundant bytes is a requirement, but I don't think the
>protocol should require it.
>
>    I myself don't see, nor have I heard any argument showing how my
>proposal for a separate operation (wh/ probably should not be called LOCK)
>to reserve a resource, separate from GETing it, is functionally inferior to
>a joined-at-the-hip checkout that is not as flexible. Maybe the REQUEST(old
>LOCK) operation needs a "GET required" status code for systems that want to
>make me consume some fresh bytes.
>
>   This brings me to a question. One of the points that I am most attached
>to is the "configuration management treated separately" requirement. The
>simplest foundation for any versioning system is to turn resource addresses
>into ordered pairs of (ID x version). Once we have that we can implement
>lots of policies on top -- the number of CM systems implemented on top of
>RCS tends to support that claim. So I'd like to hold off discussions of
>these complex policy issues until we have to get to them. And I think that
>if Content-version can serve as a cookie, then it should, because it makes
>the model for the simple stuff simpler, and doesn't add much work for a
>complex system anyway.
>
>I'm  afraid that with tabs changed to spaces by some mailer, your table of
>policies was too hard for me to decipher. But I think that this needs to go
>on hold.
>
>>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.
>
>I think we want a wide variety of version styles to work nicely. I also
>think that client requirements have to be simple to be widely implemented
>-- and if they're not to be widely implemented outside the hard-core
>configuration management community, then standardization is a waste of
>time. Why is it bad for a "checkout-style" cookie to be the same thing as
>the version-ID (ie. the Content-version header)? It works for complex
>systems and simple ones, and is less work for simple systems.
>
>I think we may have actually run this to ground. Either we're talking about
>a single field associated with a resource, and we're arguing about whether
>to call it a Cookie or a Content-version, or we're claiming that two fields
>are required. I don't see that we need two fields. In fact, I think that
>the negotiation flexibility gained in the separation of resource
>reservation from data movement makes it easier to  and negotiate the
>assignment of different version numbers at reservation and release times. I
>even think treating a cookie as a "temporary version number for the working
>version" is a nice concrete way to think of the semantics of parallel
>sessions. If we really need two fields, then we can probably postpone the
>discussion. If we don't, then I'd argue that Content-version is the name
>that should win because it best represents the simple case. But I must say
>that if we're just arguing about the name of a field I don't care, except
>for the confusion that it will cause.
>
>   -- David
>
>--------------------------------------------+--------------------------
>David Durand                  dgd@cs.bu.edu | david@dynamicDiagrams.com
>Boston University Computer Science          | Dynamic Diagrams
>http://www.cs.bu.edu/students/grads/dgd/    | http://dynamicDiagrams.com/
>
>
>

Received on Thursday, 5 September 1996 13:11:37 UTC