RE: GULP (version 4)

Yes.  I'm saying that even if we define what the state of a resource is,
servers will handle things differently and clients will constantly have
to reissue requests in order to get the right lock tokens. 

lisa

> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@gmx.de]
> Sent: Thursday, October 10, 2002 10:24 AM
> To: Lisa Dusseault; 'Julian Reschke'; 'Clemm, Geoff'; 'Webdav WG'
> Subject: RE: GULP (version 4)
> 
> Lisa,
> 
> please re-read my mail.
> 
> I was saying that we need to define what the state of a resource is.
> 
> In particular its
> 
> - content
> - internal members (depth 0 lock on collections)
> - dead properties
> - locks
> - *some* live properties (such as DAV:label) -- this is where it'll
get
> hairy, I guess
> 
> Julian
> 
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> 
> > -----Original Message-----
> > From: Lisa Dusseault [mailto:lisa@xythos.com]
> > Sent: Thursday, October 10, 2002 7:20 PM
> > To: 'Julian Reschke'; 'Clemm, Geoff'; 'Webdav WG'
> > Subject: RE: GULP (version 4)
> >
> >
> >
> > > "If a request would modify the state of a resource, the request
MUST
> > fail
> > > unless the lock-token for that lock is specified in the request."
> >
> > This isn't much more specific than the current "is affected by"
> > language.  It leaves it entirely up to the server to decide what
> > modifying the state of a resource is.  Does modifying membership
count?
> > (Is modifying membership blocked by a depth 0 lock?)  Does modifying
> > property values count?
> >
> > This is exactly where clients have had problems submitting simple
> > requests to server implementations that each have a different idea
what
> > resources have state modified by the request.
> >
> > lisa
> >

Received on Thursday, 10 October 2002 16:40:59 UTC