- From: Babich, Alan <ABabich@filenet.com>
- Date: Thu, 12 Sep 2002 12:11:18 -0700
- To: "'Roy T. Fielding'" <fielding@apache.org>, w3c-dist-auth@w3.org
-----Original Message----- From: Roy T. Fielding [mailto:fielding@apache.org] Sent: Thursday, September 12, 2002 7:01 AM To: Babich, Alan Cc: w3c-dist-auth@w3.org Subject: Re: Proposal: WebDAV and transactions ...snip... <Alan> > Between the method calls, the resources changed have to be locked on the > server. </Alan> <Roy> That's not how I described transactions. I said that the requests are collected on the server and only applied when the commit message is received. If the state has changed such that the methods are no longer applicable, then the method transaction will fail on commit. </Roy> That directly addresses the central issue, and I managed to miss that somehow. >>My whole point is that when the server actually executes the transaction, the server should have everything and do the entire transaction all at once -- retrievals, updates, and conditional processing included.<< Sorry if I didn't make that clear. If you want to dribble the instructions for the transaction over piece by piece by making separate method calls until it all gets to the server, without actually doing any updates or retrievals, that's not something that I am concerned with much. It would be more efficient to just send over all the stuff at once, but I don't think it's that big of a deal to send it over in pieces. So, doing that is OK with me. If you want the server to do some security checking and other processing on the individual pieces as they arrive, before actually executing the entire transaction in the commit step, that's fine. That would help the client pinpoint a certain subset of the possible problems in each step of the transaction. --- I think it would be interesting to see how the conditional processing of the methods is specified. How much generality is achievable without getting into syntax that doesn't resemble the current methods at all? To make arbitrary transactions convenient, you want "program" variables, conditional "statements", iteration "statements", and "subroutines" with parameters. If we don't go that far, perhaps a useful set of transactions could still be specified. I also think it would be interesting to see how the results of the transaction are specified. Any part of it could fail. Alan
Received on Thursday, 12 September 2002 15:11:50 UTC