- From: Roy T. Fielding <fielding@apache.org>
- Date: Wed, 11 Sep 2002 14:13:33 +0200
- To: "Eric Sedlar" <eric.sedlar@oracle.com>
- Cc: "Babich, Alan" <ABabich@filenet.com>, "'Julian Reschke'" <julian.reschke@gmx.de>, "Pill, Juergen" <Juergen.Pill@softwareag.com>, <w3c-dist-auth@w3.org>
> I think it is clear that the best way to address this requirement is > through > batching up WebDAV METHODS into a single request. We also have > requirements > for doing batch methods for other reasons, and I know Microsoft has also > run > into this requirement and extended the standard this way. I don't think that is clear at all. Batching methods does nothing to help with transactions that cannot be accomplished just as easily (and without breaking HTTP security) by including a transaction identifier in each request. Changing the packaging of a sequence of interrelated requests does not change the fact that they are a sequence of interrelated requests. Eventually, something has to process those requests in sequence, as a transaction. The server simply needs a way to accumulate requests and a method to commit them, and therefore it makes sense to have methods for begin-, abort-, and commit-transaction. >> If the gun refuses to shoot you in the >> foot, that is a better design for the gun. In that case, a gun that is incapable of shooting at all would be a "better" design. Considering requirements in isolation is a waste of energy. >> In the spirit of that analogy, I >> am proposing that the entire transaction, conditional processing and all, >> should be invoked by one method call. That would do a lot to help protect >> the performance of the system. It would do nothing to help protect the performance of the system. There is no effective difference between a sequence of requests with time-outs per request and a batch request with time-outs per read. The server still has to accumulate requests in storage and is subject to the same service problems with stateful behavior. The Web already has stored procedures. There is nothing preventing an application developer from building complex transactions within a single method handler. The problem is when you allow multiple methods with differing semantics to take place under the rubric of another method, which removes HTTP's ability to govern access rights per method. ....Roy
Received on Wednesday, 11 September 2002 08:14:01 UTC