W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > July to September 2001

Auto Update

From: John Hall <johnhall@evergo.net>
Date: Fri, 13 Jul 2001 15:42:05 -0700
To: "'Lisa Dusseault'" <lisa@xythos.com>, "'Tim Ellison'" <Tim_Ellison@uk.ibm.com>, "'DeltaV'" <ietf-dav-versioning@w3.org>
Message-ID: <000001c10bed$0b644580$0400a8c0@xythosjohnhall>
Actually, it isn't quite that bad, Lisa.

Assume that we use the auto-update feature as written.

Then, a server that doesn't support UPDATE should fail the checkout of a
version vs. the checkout of a VCR.

In other words:
CHECKOUT of VCR without <apply-to-version> does a IN-PLACE CHECKOUT.
CHECKOUT of VCR with    <apply-to-version> does a WORKING-RESOURCE
CHECKOUT, and UPDATE isn't required.
CHECKOUT of Version MAY fail, if UPDATE isn't supported AND 'CHECKOUT
without UPDATE' isn't supported.

So it would be nice to have a post condition on CHECKOUT of a VERSION
which said:
- A Server that supports WORKING-RESOURCE but not UPDATE MAY prohibit
the checkout of a version.  Use CHECKOUT with <apply-to-version> on the

That postcondition makes the WORKING-RESOURCE with the <auto-update>
proposal independent of UPDATE.  It would also make it clear that this
particular server did not believe in creating versions that did not
update VCR's.

Note: part of the problem is that Tim has an application in mind that
creates versions and doesn't update any version-controlled resource.
Our imaginination isn't that large, and we aren't interested in
supporting that application.

> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org 
> [mailto:ietf-dav-versioning-request@w3.org] On Behalf Of Lisa 
> Dusseault
> > > So are we back to saying that supporting Working Resource feature 
> > > requires also supporting UPDATE?  That's what I'm trying 
> to avoid.  
> > > Is there a better way for these two features to not 
> depend on each 
> > > other?
> >
> > No I'm not saying that.  I have an application in mind that creates 
> > versions and doesn't update any version-controlled resource.  It 
> > always references the versions by their version URL.  In this case 
> > there is no need for DAV:auto-update or an UPDATE method, 
> so I would 
> > object to making them required.
> That really badly serves the purposes of non-versioning 
> clients.  The server can't interact with those clients in 
> your scenario, because those clients would always just GET 
> the VCR, and end up with the root version instead of the 
> latest versions.
> Let me phrase the problem in these terms, I must find a 
> solution to: How do I write a server implementation that
>  - supports Working Resources
>  - supports non-versioning clients
> Some of the assumptions I've made in framing this problem are that
>  - UPDATE is not supported
>  - I may not be able to rely on versioning-aware clients to 
> use the auto-update flag in CHECKIN.  I don't know how to 
> send an error if they don't use this flag.
>  - It's the wrong thing to always show non-versioning clients 
> the root version.  They will never have the opportunity to 
> see the latest version.
> Lisa
Received on Friday, 13 July 2001 18:42:10 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:47 UTC