Re: further baseline-related comments on deltav-10.1

   From: Tim_Ellison@uk.ibm.com

   I find it hard to imagine an implementation that supports baselines that
   would not be able to cough up namespace information as readily as it could
   the version set. But perhaps someone has a counterexample.

Sure, I've got some (:-).

Suppose your implementation uses versioned collections, and the only
way that you can reconstruct the namespace information is by
instantiating all the collection versions in a workspace, and seeing
what namespace results.  This is not a cheap operation, and
raises various ugly implementation questions about how long you should
keep that workspace around (is the next request going to require the
same info?).

Or suppose your implementation uses a "delta" format to just store
which versions have been added/deleted from a particular predecessor
baseline.  You can rapidly find out the names of the added versions,
but it is costly to find out the names of all the versions.

   I agree that the minimal requirements are "restore" and "merge".
   (A hard-nosed person would observe that the DAV:version-set
   property is not required to meet either of these requirements.)
   But it feels like the DAV:version-set property is currently a
   half-measure; the information is of little use without the
   corresponding namespace info, which we know every implementation
   has in some form.

I'd be happy to get rid of DAV:version-set.  In fact, in an earlier
thread, the cost of computing and passing DAV:version-set was raised,
when you have, for example, a few hundred thousand resources in the
collection being baselined.  We never did address that concern ...
perhaps now is the time to do so, i.e. shall we just axe
DAV:version-set for a baseline?

   The advantage of revealing the namespace info in addition to the
   version selection is that it makes it possible for a client to
   query a baseline and reconstruct the resource
   tree---client-side---without having to create any new objects on
   the server.

This approach would not scale.  If the baseline contains hundreds of
thousands of resources, the client and server would be completely
bogged down trying to generate and process the XML.

   Currently, the only way to reconstruct the resource tree for
   browsing purposes requires read-write access. I believe there is
   benefit in enabling clients who do not have the permission to
   create new workspaces to browse the contents of a existing
   baselines. The can only do this if the namespace info is divulged
   in addition to the version set.

It would be far better for interoperability for a server to provide
"read-only" workspaces for such a client.  This is not only simpler
for a client (it just accesses the namespace, instead of trying to
reconstruct it), but also gives the server the key information it
needs as to how long to keep around this "queryable" form of a
baseline.

Cheers,
Geoff

Received on Thursday, 19 October 2000 16:22:14 UTC