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

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

From: Christopher Seiwald <seiwald@perforce.com>
Date: Tue, 3 Sep 1996 22:30:44 -0700
Message-Id: <199609040530.WAA05546@spice.perforce.com>
To: w3c-dist-auth@w3.org, www-vers-wg@ics.UCI.EDU
This is my last volley on this subject.  I promise!

| From: "David G. Durand" <dgd@cs.bu.edu>
| 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.

CHECKOUT is, I believe, your LOCK method renamed.  The LOCK that I talk
about is the securing of the right to PUT the next rev of the document.

I admit that I would require a special GET (namely CHECKOUT), but it could
do the double-duty of CHECKOUT and "GET for EDIT" (with apologies to Yaron).
As for the extra bytes, there are already mechanisms where a client can
"GET if different", so that shouldn't be a concern.

|     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.

Or, as I said, CHECKOUT can, like GET, have "if different" tags to tide
the flow of data.

|    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.

This may be shortsighted.  I'm not an expert in distributed web authoring,
but I know configuration management, and I offer this: a cookie _of the
server's choice_ will carry the semantics of all config mgmt systems out
there; a cookie of our design will not.  Content-version is a fine name
for this cookie (but not my first choice).

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

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