RE: Feature request for CHECKIN/OUT extension

> From: Julian F. Reschke [mailto:julian.reschke@greenbytes.de] 
> 
> > From: ietf-dav-versioning-request@w3.org
> > [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of John Hall
> > Sent: Tuesday, August 07, 2001 12:12 AM
> > To: 'Julian F. Reschke'
> > Cc: ietf-dav-versioning@w3.org
> > Subject: RE: Feature request for CHECKIN/OUT extension
> >
> >
> > Well, I personally expect the CHECKIN URI to be the same as the 
> > CHECKOUT URL.
> 
> When using the checkout-in-place feature, the URI of the VCR 
> (that the client is editing) will not be the same as the URI 
> of the version that is created upon CHECKIN, right?


Ok, I misunderstood.

But I don't think this is very useful for a cross-platform client, and I
think there is another way to do it.

In the checkout-in-place scenario, you do something like this:

CHECKOUT /foo.txt
PUT      /foo.txt
PUT      /foo.txt
CHECKIN  /foo.txt

As far as I'm concerned, the only URL the client should be displaying is
/foo.txt.  However, you want to know the URI that references the VERSION
being created above, independent of the VCR /foo.txt.

You can get that value by asking for the checked-out property.  But on
my system you are going to get something that looks like
/_xy-2-1100.4301.docStore1.  Version URL's on my system are most
definitely not designed to be human readable, and are not intended for
display.  I've seen other URLs that a different server generates that
look like /_flaturlspace_/4023-e214 ... You get the idea.

You could ask for the version-name.  On my system you'd get a string
like 'foo.txt (V5)'.  The version-name is meant to be human readable and
useful for display, unlike the internal URL.

And Geoff is quite right.  Though I could (and will if you ask for
checked-out) give you the Version URL, I can easily imagine a system
that generates a different (permanent) one when it checks it in.

Received on Thursday, 9 August 2001 10:07:03 UTC