Re: Seiwald Q & A -- "GET for EDIT" cookies -- final volley
Christopher Seiwald (seiwald@perforce.com)
Tue, 3 Sep 1996 22:30:44 -0700
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).
Christopher