RE: Version-controlled collection resources - I am still missing something

"Clemm, Geoff" <gclemm@rational.com> wrote:

> Introducing an empty root version will have no
> significant implementation cost, and logically,
> it is very reasonable to say that every new
> collection starts out empty, so there is no
> conceptual problem here with users encountering
> a root version that is empty.

I disagree that users would reasonably expect to see an empty collection
version.  I only expect to see versions that capture states that I'm
interested in (the initial empty state is not one of them).  But, other
than the fact that I wouldn't want to rely on it, that is something of a
digression...

> But whether or not an empty root version is "bogus"
> or "sensible" (:-), the VERSION-CONTROL request is
> not expensive, because a server can easily leave an
> "uninitialized" value for any such binding, and only
> retrieve the root version if the client actually
> requests a value from an unitialized binding.

I agree that the server can be lazy, the question is what value should a
client see if it looked?

>    From the client's perspective, is it any better
>    to have no members of the version-controlled
>    collection (and have to fill them in explicitly),
>    or have the root versions for each member (and
>    likely have to go and update them explicitly)?
>    I accept that for the server it is easier to not
>    create members.
>
> The server can use basically the same implementation
> in either case.  The only question is whether it returns
> some "uninitialized" status when you encounter one of
> those internal members, or returns the root version.

I agree that is the issue, unless we identify another candidate.

> Note that since the client is extremely likely to follow
> the VERSION-CONTROL request with the appropriate MERGE or
> UPDATE request, a client won't be encountering these
> "uninitialized" bindings very often anyway.

Agreed.

>    The members of a version-controlled collection created
>    from a collection version are:
>    (1) the DAV:root-version of the member's history (as
>    proposed) an implementation note should be added to
>    state that severs may chose to make root-versions of
>    versioned collections empty to avoid cascading
>    version-controlled collections.
>
> or could just implement them as "uninitialized", and only
> retrieve the root version if the binding is used before it
> is explicitly initialized.

I don't want to get too much into implementation at this stage, though I
agree with your observation.

The question at hand is whether the spec should be changed (as proposed) to
define the default value of such a binding.  If we believe that the client
will always fix-up the binding anyway the answer may as well be 'no'.

>    (2) undefined and have to be explictly created by another
>    version-control/merge request.
>    i.e. when the version-controlled collection is created
>    a PROPFIND depth 1 would answer the internal member names,
>    but attempts to GET them would return 404 Not Found.
>
> I considered this, but it introduced what appears to be an
> unnecessary obscure case (you'd need a DAV:uninitialized-binding-set
> so that a client could discover what was going on here).  Note:
> I'm not against this, but just thought the current way was simpler.

I tend to agree.  Although we did have it this way months ago, I think it
is likely to be confusing, so I'd happily rule this option out.

>    (3) the spec is silent and servers do what they choose.
>    It seems that clients are very likely going to have to go
>    and fix-up all the members anyway so who cares about the
>    initial value.
>
> Yes, although I think it is better to define the behavior, so I
> prefer 1 or 2.

I kinda like this one, but can see the benefit of defining the behavior;
it's just too bad that the DAV:root-version is unlikely to be a useful
choice for most clients.

>    (4) forget that I even mentioned "latest" :-(
>    Geoff wrote:
>    > "latest" is a very bad choice ... I believe that selecting
>    > the DAV:root-version is significantly superior.
>    I agree that leaping around across branches is less than optimal,
>    I was stumbing towards Alan's notion of the "linear series"
>
> Note that this effectively would bundle "MERGE from activity"
> into the VERSION-CONTROL request.  One of the reasons I resist
> bundling any of these into the VERSION-CONTROL is that any variant
> of the MERGE or UPDATE request is reasonable following the
> VERSION-CONTROL request, so we'd have to give VERSION-CONTROL
> all the semantics of MERGE and UPDATE if we wanted to do this
> cleanly.

I agree.

> Since I believe that there are several techniques a
> server can use to make the initial VERSION-CONTROL request very
> inexpensive (described above) , I think it is cleaner to keep
> them separate.

I agree that it is cleaner to keep them separate (despite the server
implementation).

I'm mildly in favor of leaving it undefined, and mildly in favour of making
it the DAV:root-version, and strong in favor of selecting the 'right'
version <g>  (... we could have these revision selection rules that
...hmmm)(joke)
Regards,
Tim

Received on Thursday, 5 July 2001 11:07:16 UTC