Re: new auto-version value

I'm a little confused.  If you don't want the user to have to go to the 
external state-manipulation tool, then why not use 
checkout-unlock-checkin?  I would think you would want the checkin to 
happen when editing is done, to publish the state.  Also note that the 
state is "published" regardless, in that any changes made by any client 
are visible on the resource checked out, whether or not it's checked in 
again -- it seems pretty clear in this case you're talking about 
in-place checkout.

The auto-version property is a bit of a hack to deal with 
non-DeltaV-aware clients that can never know when to check out and 
check in.  Adding more values to this property runs a risk of confusing 
DeltaV clients that are aware of this property but only know the values 
in the initial standard.  OTOH I'm not aware of any clients at all that 
use the value of this property as yet so it would be good to hear if 
there are any.

Lisa

On Jun 18, 2004, at 6:14 AM, <webdav-standards@webdav.info> wrote:

>
> Hello,
>
> the auto-version property can currently hold 5 different values: 
> Empty, checkout-checkin, checkout-unlock-checkin, checkout and
> locked-checkout.
>
> I would like to propose a new value, named something like: 
> checkout-ignore-unlock. It will carry the same semantics as the
> checkout value, but an unlock command will not issue an implicit 
> check-in command, instead the resource stays in the checked-out
> state and an explicit check-in command is required.
>
> Use-case:
>
> A document is controlled by a workflow process. Creating a document 
> takes this document in the initial-author state, in which only
> explicit check-in command should create new versions. If this newly 
> created resource is implicitly put under version-control and
> the auto-version property is set to the new suggested value, we can 
> receive this behaviour. Now the document can be modified
> either with an http client (via put) or with a WebDAV client (Lock - 
> Put* - Unlock) and still the resource is never implicitly
> checked-in.
> The same effect could be reached by an explicit check-out, but this 
> will require an additional user interaction to issue the
> check-out command, which we do not want to expose. Our user is then 
> only required to use our state manipulation GUI tool, in case
> of a real state change. The creation and manipulation of a new 
> resource will feel like modification on the hard disc: create it,
> modify it (with any tool) and then publish or change the state with an 
> additional tool.
>
> Does this make a more general sense, or would you think this is a too 
> specific requirement to go into any new version of the
> delta-v standard?
>
>
> Best regards
>
> Juergen Pill
> Premium WebDAV Consultancy and Services
> www.webdav.info
>
>
>
>

Received on Friday, 18 June 2004 10:56:45 UTC