Re: Re2: what's doable in Web version control
Larry Masinter (masinter@parc.xerox.com)
Mon, 10 Jun 1996 22:35:04 PDT
> Is this why the update is multipart? so that several URLs can be
> updated in a single operation? This seems one way to get
> transactions.
Yes, that's right. I think adding transactions to the web using some
explicit COMMIT operation is probably wrong. Rather, just have a POST
be the transaction. POST commit data if you must.
I'm interested in pushing the complexity of version management into
GET and POST partly because most of the issues are orthogonal to the
deployment of caching, proxies, updates, transactions, etc. that have
dominated the design of GET and POST. If we can create a world where
there are three operations: GET, PUT (for simple replace) and POST
(for anything else) and all of the rest of the complexity is in the
data that's sent back and forth, I think it will be a model that will
survive the transition of HTTP to HTTP-NG, the use of this kind of
update mechanism using email as well as using direct web transactions,
etc.
I'm re-reading the VTML document, but I don't think what I intended
for "multipart/update" matches what VTML does.
What I *intended* was basically just a replacement for (one or more)
PUT operations, which contained a set of headers that were appropriate
for an update. VTML seems like it's much more a representation -- in a
single file -- of a versioned resource.
I'm sorry for waving about a name ("multipart/update") without giving
a binding for it, since it leaves too much to the imagination.
On a completely separate subject: is there a meeting July 8 then?
Larry