Re: Seiwald Q & A -- "GET for EDIT" cookies -- final volley
Christopher Seiwald <email@example.com> scribit:
>This is my last volley on this subject. I promise!
>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 still don't see why CHECKOUT should not be completely separate from GET.
We get more flexibility for non-locking systems, and equivalent
functionality for your kind of system. We may be in raging agreement on the
need for a "reservation" function to bracket updates for some systems.
Since GET already has If-modified, I don't see why we need a new operation.
We need to be careful about how we think about this as well. It asserts the
intention of the client to update the document, and may invoke various
locking behaviours if the server needs to do that. Maybe we can use
something like Jim's suggested FLAG methods to implement locking in the
>Or, as I said, CHECKOUT can, like GET, have "if different" tags to tide
>the flow of data
But why is the more-specialized operation better? Keeping the notion of
reservation separate fromt he notion of fetching makes a simpler, more
flexible protocol that seems to meet the need you've identified (server
>| 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).
Since version numbers have always been opaque server-determined strings
(The final decision _must_ belong to the server by definition) I don't see
that we've added a requirement here. We never proposed to design version
identifier formats, and I agree that we can't. (I guess we may have to pick
a character set and quoting convention, but I can't see any reason to do
David Durand firstname.lastname@example.org | david@dynamicDiagrams.com
Boston University Computer Science | Dynamic Diagrams
http://www.cs.bu.edu/students/grads/dgd/ | http://dynamicDiagrams.com/