Re: Mutable Versions (was: re-use of version URL's)

   From: "Lisa Dusseault" <lisa@xythos.com>

   What it seems you're trying to do is make the server models for mutable
   and immutable versioning interoperate.  However, I don't think that's
   necessary.  For interoperability, we only need *clients* to be able to
   understand what the server is doing.

If an option is something that is just passed on to the user,
like "should I have a MERGE operation in the menu", then it's
reasonable to expect client implementors to deal with it.

If it's something as fundamental as "can I count on the resource
at this URL never changing in value" (which affects caching,
whether you use it in delta update requests, whether you can
store it in dead properties as a reliable reference, etc),
then it is unlikely that a client will be written to handle 
both ways.

If we didn't have an interoperable alternative, I'd be inclined
to let it go, but the "delete predecessor on checkin" appears
to give us the interoperability we need for a single client to
(easily) work consistently against both kinds of servers.

   We already know that clients will
   have to be able to find out if servers support mutability or not; if
   they do, it's not that hard for the client to have a slightly different
   model of what's going on.  Any client developers want to chime in here?

With the "delete predecessor" approach, a client will not have to
find out if a server supports mutability, because the two models
will be consistent.

   In what way is the "mutable version option" incompatible with merging,
   baselines, or activities?

For merging, when you merge an ancestor into one of its descendants,
you just get the descendant, because you know that all changes in
the ancestor have been carried forward into the descendant.  If you
let the ancestor be modified after the descendant is created, this
breaks this semantics.  If on the other hand, modifying the ancestor
always creates a new version URL, then the system will not think that
the modified version is an ancestor, and will know that the two
versions will need to be merged.

Similarly, for activities, you can count on the "latest" version in
an activity as containing all the changes from earlier versions in
that activity, but this semantic is broken if you can modify earlier
versions without generating a new version URL.

Finally, baseline implementations depend on the fact that you can
capture the state of a collection by remembering the version URL's
for the versions in that collection.  If you can modify a version,
this list of version URL's will no longer capture that state of
the collection (you would have to actually store the contents of
each member).

   Normally I wouldn't propose two such divergent server models, but in
   this case I'm coming to believe that the document versioning model is
   almost incompatible with the code versioning model.  They might not be
   able to coexist on the same server, or at least in the same namespace.

Yes, then we've pretty much given up on interoperability (you
basically have to write two clients).  I'd like to see what is wrong
with the delete predecessor semantic before giving up.

Cheers,
Geoff

Received on Saturday, 6 January 2001 00:18:03 UTC