RE: GULP (version 4)

> From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On
> Behalf Of Lisa Dusseault
> Sent: Thursday, October 10, 2002 11:57 PM
> To: 'Webdav WG'
> Subject: 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.

Then is hasn't been clarified.

If a specification defines locking, but doesn't define what operations on
locked resources require submission of the lock token, then in doubt a
client always has the choice of submitting the lock token. Servers that
don't require it will just ignore it. So where's the big issue with that?

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

Yes. Bad design. I don't see how anything you are proposing would help with
that problem? Either you need the lock token or not. I though the discussion
was about the topic on *how* to submit it.

Obviously, there always can be hidden server-specific dependencies on other
resources that may be locked. If the server wants to enforce these locks,
there's obviously no simple way for non-proprietary clients to interact with
it.

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

That would be a computed live property that would better be not
lock-protected. If it is, generic clients will have a problem because they
won't expect this.

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

That would be a bug (IMHO).

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

The state of the collection changes. The state of the member doesn't.

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

The state of the collection doesn't change. The state of the member does.

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

I think we don't have a choice but to define the model.

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

I'd prefer to have a generic model that explains all these requirements,
because it would also automatically apply to new methods. However, it surely
makes sense -- after getting the generic model right -- to write down what
this actually means for all specific methods. The important point is to get
the underlying model right first.

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

I don't agree. If you're talking about the "new" header, it doesn't give the
client any new freedom. It just allows a simpler syntax. It could use the If
header instead.

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

Yes. But the outcome might as well be that some existing protocol element
hasn't been understood properly and already does what the client implementor
is asking for. In particular, you *can* use the If header to submit any
number of lock tokens you have -- no matter whether they are required or
even in effect. If this doesn't work yet in practice, let's clarify the spec
and fix the implementations instead of inventing something new.

Julian

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

Received on Friday, 11 October 2002 04:04:25 UTC