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 
>

Received on Friday, 16 April 1999 16:48:54 UTC