Re: Must PROPPATCH operation be atomic...

I definitely think besteffort vs. atomic operation is very valid
real-world scenario. What we have done is added an XML tag called sync,
whose value determines the behaviour for the PROPPATCH, PROPFIND or
SEARCH methods. So the XML element would be <D:sync>besteffort</D:sync>
or <D:sync>atomic</D:sync>. Ofcourse in order to maintain compatilibity
the default would be "atomic".

Thanks,
Imran


--- "Geoffrey M. Clemm" <gclemm@tantalum.atria.com> wrote:
> 
>    From: "Lisa Lippert (Dusseault) (Exchange)"
> <lisal@exchange.microsoft.com>
> 
>    I've been thinking about this some more, and I
> believe both are valid
>    scenarios.  There are scenarios where the client
> wants to have all succeed
>    or none, and there are scenarios where the client
> wants to have as many
>    succeed as possible.
> 
> I agree.
> 
>    Really, it's too bad clients don't have some
> simple switch to say whether
>    this should be treated as an entire transaction
> or not.  Then servers that
>    don't support the model that the client asks for
> could fail the operation
>    right away.
> 
> And if someone feels the alternative behavior (where
> as many succeed
> as possible) is worth the time and effort to define
> and get accepted,
> he/she should join or form a working group to define
> such an extension
> to the base WebDAV spec.
> 
> Cheers,
> Geoff
> 
>    > -----Original Message-----
>    > From: Yaron Goland 
>    > Sent: Friday, April 16, 1999 2:25 PM
>    > To: Lisa Lippert (Dusseault) (Exchange); 'Brian
> Lloyd';
>    > 'w3c-dist-auth@w3.org'
>    > Cc: 'gstein@lyra.org'
>    > Subject: RE: Must PROPPATCH operation be
> atomic...
>    > 
>    > 
>    > To quote section 8.2:
>    > 
>    > Instructions MUST either all be executed or
> none executed. 
>    > Thus if any error occurs during processing all
> executed 
>    > instructions MUST be undone and a proper error
> result returned. 
>    > 
>    > I apologize if this language is not
> sufficiently clear.
>    > 
>    > As for multi-status, it is a compound response
> format. While 
>    > a single error is sufficient to cause a
> PROPPATCH to fail the 
>    > system may be programmed to send out commands
> to set all the 
>    > properties and then to roll back if one or more
> fail. The key 
>    > is, one or more. 
>    > 
>    > For example, a client sends in a PROPPATCH with
> changes to 
>    > four properties. The server sends a command to
> its property 
>    > store to change all four properties. The
> property store sends 
>    > the server back a message saying that three of
> the property 
>    > set commands failed and one succeeded. The
> server then orders 
>    > a roll back. However the server wants to be
> able to tell the 
>    > client exactly what went wrong. That is, the
> server wants to 
>    > send a message to the client saying "Your
> request failed. The 
>    > reason it failed is that there were the
> following errors on 
>    > three of your properties." To do this the
> server needs a 
>    > compound error response format and that is what
> multi-status does.
>    > 
>    > As for why we have the atomicity requirement
> please refer to 
>    > the section entitled "<"This is another fine
> protocol you've 
>    > gotten me into!">" in 
>    >
> http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0
>    > 303.html. I believe the second paragraph
> exactly answers your 
>    > question. Although it seems that my comment
> regarding 
>    > compliance with the atomicity requirement is
> wrong. Most 
>    > folks apparently have implemented it. I think
> that rocks! I 
>    > will eventually have to update the WebDAV book
> of why to reflect this.
>    > 
>    > 			Yaron
>    > 
>    > > -----Original Message-----
>    > > From: Lisa Lippert (Dusseault) (Exchange)
>    > > [mailto:lisal@exchange.microsoft.com]
>    > > Sent: Friday, April 16, 1999 1:48 PM
>    > > To: 'Brian Lloyd'; 'w3c-dist-auth@w3.org'
>    > > Cc: 'gstein@lyra.org'
>    > > Subject: RE: Must PROPPATCH operation be
> atomic...
>    > > 
>    > > 
>    > > So what does multi-status mean??
>    > > 
>    > > Ideally there would be a way for the client
> to specify 
>    > > atomicity, but we
>    > > don't have that yet.
>    > > 
>    > > Lisa
>    > > 
>    > > > -----Original Message-----
>    > > > From: Brian Lloyd
> [mailto:Brian@digicool.com]
>    > > > Sent: Friday, April 16, 1999 1:57 PM
>    > > > To: Lisa Lippert (Dusseault) (Exchange);
> 'w3c-dist-auth@w3.org'
>    > > > Cc: 'gstein@lyra.org'
>    > > > Subject: RE: Must PROPPATCH operation be
> atomic...
>    > > > 
>    > > > 
>    > > > > I know this is an old conversation, but
> the email got 
>    > buried in my
>    > > > > mailbox...
>    > > > > 
>    > > > > Some PROPPATCH results can fail and
> others can succeed, so 
>    > > > > this is why we
>    > > > > have multi-valued responses.  Clients can
> easily see what 
>    > > happened.
>    > > > > Rollback is difficult for servers to
> implement.  Are there 
>    > > > any server
>    > > > > implementations that do already implement
> this as atomic or 
>    > > > > with rollback?
>    > > > > I'm not aware of any.  I see rollback as
> a more advanced 
>    > > > > feature, that we
>    > > > > can figure out how to do later on.
>    > > > > 
>    > > > > Lisa
>    > > > 
>    > > >  Zope (web application server) implements
> atomic PROPPATCH 
>    > > > w/rollback. We lucked out in this respect,
> as Zope is
>    > > > based on a transactional object database
> which made this
>    > > > relatively painless.
>    > > > 
>    > > > While implementing it on a
> non-transactional server is harder,
>    > > > it still (IMHO) seems to be a requirement.
> Clients that respect 
>    > > > the rfc will have an expectation that a
> failure means no changes 
>    > > > were made. If this is not the case, you
> might have any number
>    > > > of caching and resource integrity problems,
> based on mismatched
>    > > > expectations on the part of the client and
> server...
>    > > > 
>    > > > 
>    > > > Brian Lloyd        brian@digicool.com
>    > > > Software Engineer  540.371.6909            
>  
>    > > > Digital Creations  http://www.digicool.com 
>    > > > 
>    > > 
>    > 
> 
> 
> 

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Received on Wednesday, 21 April 1999 15:50:27 UTC