RE: Question on support for in-place editing

   From: John Hall [mailto:johnhall@evergo.net]

      From: Lisa Dusseault [mailto:lisa@xythos.com]

      By "in-place editing" I mean that when the VCR is checked out,
      clients can do any number of PUT, PROPPATCH and other write
      operations, before finally checking in.  In the meantime, this
      work-in-progress is available for other users to see if they have
      permission to read the resource.

      First question: Does anybody plan to implement DeltaV this way?

   I would strongly consider this an option, if a default GET and PROPFIND
   did not reference the work in progress but instead referenced the
   last-checked-in-version.

That is how working resources work.  The
version-controlled resource URL is a copy of the state of some
checked-in version (but not the last checked-in version,
but rather the last version specified in an UPDATE).

The working resource has its own URL, and that is what the client
that "checked it out" works with.

In-place editing is precisely for those cases where you want the
all clients to see "work in progress" at that URL (to see a
checked in version, you look at a URL in a different workspace).

   Imagine this:
   After checkout, GET/PROPFIND from users that don't have the resource
   checked out refer to the last checked in copy.  PUT/PROPPATCH are
   illegal.

The easiest way to determine "which user has it checked out" is to
give the "checked out version" its own URL.  And PUT/PROPPATCH are
illegal (unless your server has auto-versioning turned on).

   For the user with the resource checked out, all operations apply to the
   checkout-in-place copy.

   That gives you most of the functionality of the working resource model,
   avoids things like UPDATE/MERGE interactions with working resources, and
   avoids placing extra demands on the client.

And how does a client indicate which checked out state it wants to
access?  Why make a client remember two strings (the checked-out "token"
and the URL), which it only needs one string (the working-resource URL).
(We need to support parallel checkouts, so a "the checked-out one"
header does not suffice).

   If we weren't trying to be compatible with a 3rd party DAV + revision
   but not DeltaV server, I'd propose that we do it this way.  The 3rd
   party server puts the working resource in an independent namespace.

So you actually don't propose we do it this other way?  Then we agree (:-).

Cheers,
Geoff

Received on Tuesday, 12 June 2001 22:09:12 UTC