RE: GULP (version 4)

"If we get the clarification right"?  A definition that involves
discussing properties, locks, and content in a way that is generic, will
result in a different conclusion for servers that do things differently.
The model can be 'clarified' for years and still be interpreted
differently.

 

Imagine we try to define a model for what constitutes a state change. 

 - What if a server, when you issue a DELETE, actually moves a file to
the trash can folder? What if the trash can folder is locked? Clearly,
it requires that lock token.

 - What a particular implementation decides that add a file to
/mydir/sub/dir actually changes a property value on /mydir?

 - What if the contents of a file are defined to import the contents of
another file?  The server implementation might define that as a content
change.

 - Does a collection's members state change if a file is renamed? 

 - Does a collection's members state change if a file is overwritten?  

My point is that models are hard to do right.  It's very tempting to
work on tweaking the model, when that might not be as effective as
simply specifying exactly what's supposed to happen in a particular
case.

 

In contrast, let's examine another way of "fixing" this problem by
putting additional specification requirements on the server.  Rather
than say a lock affects changing state in certain ways (the 'generic'
approach), we could define for each method what locks must be had.  For
example:

 - For DELETE requests, if the DELETE target is locked, or the DELETE
target parent is locked, those locks are affected.

 - For COPY requests, if the COPY target is locked, or the COPY target
parent is locked and the COPY target does not exist, those locks are
affected.

 - etc.

 

Let's go meta for a minute anyway.  There are at least two ways that
have been discussed to approach this "problem".  One way is to give the
client more leeway.  The other is to make things more restrictive for
the server - either through the generic approach of defining state, the
specific approach of describing requests.

 

Client implementers encountering this problem have asked for more client
leeway, NOT for more server restrictions.  I consider it perfectly valid
to restate the problem and try to find a different solution -- I do this
often and consider it a good design habit.  However, one must always be
careful to make sure one is really solving the right problem when one
does this.

 

lisa

 

> -----Original Message-----

> From: Julian Reschke [mailto:julian.reschke@gmx.de]

> Sent: Thursday, October 10, 2002 2:21 PM

> To: Lisa Dusseault; 'Julian Reschke'; 'Clemm, Geoff'; 'Webdav WG'

> Subject: RE: GULP (version 4)

> 

> Lisa,

> 

> > 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.

> 

> Why that? If we get the clarification right, the only issue would be

> non-conforming implementations. And obviously there's no way we can

> guarantee interoperability if implementations do not comply with the
spec.

> 

> Julian

> 

> --

> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

> 

> > -----Original Message-----

> > From: w3c-dist-auth-request@w3.org

> > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault

> > Sent: Thursday, October 10, 2002 10:40 PM

> > To: 'Julian Reschke'; 'Clemm, Geoff'; 'Webdav WG'

> > Subject: RE: GULP (version 4)

> >

> >

> >

> 

> >

> > 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

> > > >

> >