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 12:49:11 UTC