DAV:bindings-last-modified (was RE: DAV:getlastmodified of collections)

I believe that we have concluded that DAV:getlastmodified depends on
what the server returns on a GET on a collection, and therefore is not
something we can define (since what the server returns on a GET on a
collection is not defined).  So what we are really talking about in
this thread is a new property (which without much thought, I've named
DAV:bindings-last-modified).

This raises the key question: what will the client be using this new
property for.  I suggest it be used to keep the structure of a client
tree display synchronized with the names and resources on the server,
in which case the client doesn't care whether the version-controlled
state changes, as long as the named tree of resources is still valid.

Cheers,
Geoff

> > "Julian Reschke" <julian.reschke@gmx.de> wrote on 09/05/2003 06:08:11 
PM:
> > > But then we're missing the case of VERSION-CONTROL on a versionable 
but not
> > > yet version-controlled resource that lives inside a versioned 
collection (in
> > > which case I'd say the state of the parent collection *does* 
change).

> > Geoffrey M Clemm
> > I suggest we keep the semantics very simple, and say that 
DAV:getlastmodified
> > is changed only by adding a binding, removing a binding, or changing a 
binding
> > to new resource.  Putting an existing resource under version control 
does
> > none of these things, so it should not result in an update to
> > DAV:getlastmodified.
> >
> > Note that in general the "version-controlled state" of a collection 
will be
> > different from the "state" of a collection, i.e. adding and removing a 
binding
> > to a non-version-controlled resource does not change the 
version-controlled
> > state of a collection, but does change the state of the collection.
 
"Julian Reschke" <julian.reschke@gmx.de> wrote on 09/08/2003 09:45:20 AM:
> This seems to imply that the version-controlled state is not a subset of 
the
> state, or more precisely, that you can modify the version-controlled 
state
> without changing the state. This IMHO seems to be a weird way to define 
the
> state of a collection.

Received on Monday, 8 September 2003 11:19:13 UTC