- From: Stefan Eissing <stefan.eissing@greenbytes.de>
- Date: Wed, 9 Jan 2002 16:46:48 +0100
- To: "Clemm, Geoff" <gclemm@rational.com>, "WebDAV" <w3c-dist-auth@w3.org>
> From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Wednesday, January 09, 2002 4:17 PM > To: WebDAV > Subject: RE: Interest in standardizing Batch methods? > > > A single MOVE, DELETE, or PROPPATCH request is idempotent > (repeating the same request multiple times produces the > same result as just doing it once). Not quite: A second MOVE/DELETE/PROPPATCH will return a different result to the client. So a second DELETE will answer 404 instead of 204. The server "state" will stay the same. I think that's what you had in mind. > A sequence of DELETE's is always idempotent. A sequence of PROPPATCH's > is always idempotent if the same property isn't updated by different > PROPPATCH requests in that sequence. A sequence of MOVE's is always > idempotent if none of the Destination URLs overlap with any of the > request URL's. > > Cheers, > Geoff > > > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Wednesday, January 09, 2002 3:34 AM > To: Lisa Dusseault; Greg Stein; Jim Whitehead > Cc: WebDAV > Subject: RE: Interest in standardizing Batch methods? > > > Looking at RFC2616: > > "8.1.2.2 Pipelining > Clients SHOULD NOT pipeline requests using non-idempotent methods or > non-idempotent sequences of methods > (see section 9.1.2). > > So it seems that pipelining wouldn't be allowed for anything > except PROPFIND > (MOVE/DELETE/PROPPATCH aren't idempotent), right? > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > > Sent: Wednesday, January 09, 2002 6:30 AM > > To: Greg Stein; Jim Whitehead > > Cc: WebDAV > > Subject: RE: Interest in standardizing Batch methods? > > > > > > > > > Personally, I'm going to guess they didn't pipeline requests, > so a batch > > > mechanism was a must to get around deficiencies in their > protocol stack. > > > > There's potentially a little more to it than that. > > (1) Imagine a client selects a bunch of resources and drags to > > move them all > > to a different folder. A batch MOVE operation can do those in one > > transaction, so that the whole request fails if not all can be > > moved. This > > becomes rather more important if the client is actually using an API > > (MSDAIPP??) that offers large-scope operations, yet how can it guarantee > > that operation will work or won't work if it can only send it > piecemeal to > > the server? > > > > (2) See Yaron's email > > (http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0303.html) > > about why pipelining doesn't always work (can't always be used even when > > available). I don't know to what extent pipelining is realistically > > unavailable/unworkable. > > > > That said, it's still not clear batch methods are so necessary they'd > > preempt other work we've got to do. > > > > Lisa > > > > >
Received on Wednesday, 9 January 2002 10:47:41 UTC