AW: VERSION-CONTROL with Location header?

Tim,

thanks for taking the time for this informative answer.
I did not consider the example with the working resource
being deleted on a checkin, which makes the Location
header a necessity. This is indeed not the case with
VERSION-CONTROL.

However, in Section 3.5 it says:
"If the request-URL identifies a version-controlled resource,
the resource just remains under version-control.
This allows a client to be unaware of whether or not a server
automatically puts a resource under version control when it
is created."

Which I read more like "...keeps the client from knowing
whether there was anything done to the resource or not."

See, I'm implementing WebDAV client/gateway code which works
against a remote WebDAV server. Due to performance reasons
I have to cache resource state (at least for a short time).
So, it would be nice to know if VERSION-CONTROL changed the
resource or not (keeping my cache valid). This could be done
with a Location header or via the response code, whatever.

An optional Location header would have the advantage, that
client can be unaware, if they wish, while clients which like
to know can look for the header.

Stefan


However, as you mentioned,
> Von: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]Im Auftrag von
> Tim_Ellison@uk.ibm.com
>
> "Stefan Eissing" <stefan.eissing@greenbytes.de> wrote:
> > I scanned the archives, but could not find anything about
> > this. In case I missed it, my humble excuses for posting
> > this again:
> >
> > The response to a VERSION-CONTROL request does not carry
> > a Location header similar to CHECKIN (Draft 15). Now, I
> > would propose that the client receives such a header
> > in case the resource changed status from versionable to
> > versioned (and is now checked-in).
>
> When VERSION-CONTROL is applied successfully to a versionable
> resource, the
> versionable resource is _replaced_ by a checked-in version-controlled
> resource (i.e., the version-controlled resource is identified by the same
> URL that previously identified the versionable resource).  No 'Location:'
> header is therefore required to identify the version-controlled resource.
>
> The resulting checked-in version-controlled resource has a
> <DAV:checked-in>
> property whose value is the URL of the version with the same content and
> dead properties.  This version URL can be used as a 'stable' reference to
> the content and dead properties.
>
> The Location: response header is provided with CHECKIN because it
> gives the
> client the URL to the version that was created by the successful check in.
> This becomes important when checking in a working resource as the working
> resource is deleted upon a successful check in.  (When checking in a
> checked-out version-controlled resource the Location: response is the same
> as the resulting checked-in version-controlled resource's <DAV:checked-in>
> property value.)
>
> > Scenario: with basic versioning a user might have checked
> > out a number of resources for editing. Now he adds a couple
> > of new resources which are initially not under version control.
> > Then he (or rather his client application) tries to check in
> > all resources he has created or changed, issuing CHECKIN and
> > VERSION-CONTROL requests.
>
> Note that when a client checks out resources for editing, they may be
> checking out a (checked-in) version-controlled resource which simply makes
> it become a checked-out version-controlled resource (effectively 'marking'
> the resource mutable); or they may check out a version which
> creates a new,
> mutable, resource (a working resource).  I'll assume that you are checking
> out one/more version-controlled resource(s).
>
> > Outcome 1: all requests succeed and the client application
> > can display the version URIs of the checked-in versions to
> > the user by using the Location headers of the responses.
>
> The version URLs are typically meaningless to the user.  They will be
> unique, server generated URLs.  Unless it is important for users to deal
> with the versions directly, it is likely they will deal with the
> checked-in
> version-controlled resources.  As mentioned above, their URLs are more
> likely to make sense in the users' application.
>
> > Outcome 2: resources were checked in our put under version
> > control by someone else. In this case the client application
> > can be aware of the modified resource by
> > a) failed CHECKIN requests for already checked in resources
>
> Right.  CHECKIN will fail if the resource is not version-controlled, or is
> already checked-in.  VERSION-CONTROL will succeed (200 OK) if the resource
> is already under version-control.
>
> > b) missing Location headers for resource already under version
> >    control.
>
> Not sure what you mean here.
>
> > Does this make sense to anyone but me?
>
> Where a client expects some isolation from other clients, they would
> typically use working resources (client-side workspace scenario) or a
> workspace resource on the server (server-side workspaces).
> Where there is overlap and clients are 'bumping into each other' in the
> manner you discuss, then they have to react to return codes to determine
> the state of the resources and PROFIND to probe their current state (i.e.
> for UI updating).  This is less than ideal.
>
> Tim
>
>
>
>

Received on Friday, 11 May 2001 07:21:12 UTC