RE: Resolving outstanding issues in DeltaV

From: Lisa Dusseault [mailto:lisa@xythos.com]

   I'd be happy to be in the conf call and bring up what I see as two
   major remaining problems.  They are not merely marshalling
   problems.  If it were my implementation design that had these
   problems, I would call them "showstoppers".

I'll add these issues to the agenda for the call.

   1. Stored resources can get lost, or unfindable.  This happens when
   VCRs are deleted (possibly by clients that don't understand
   versioning).  The problem is that even versioning-aware clients may
   not subsequently be able to find the VHRs and Version resources
   that are thus orphaned.  This is a memory leak.

A garbage collector that deletes objects that still have references to
them is as much of a bug (and arguably, more of a bug) than a garbage
collector that misses some objects.  Since a reference to a resource
can appear in some dead property or in the content of an HTML resource
or even in some email message, we have no good way of determining
whether there are any outstanding references to a particular Web resource.
Of course, that doesn't mean that we can never remove resources from
web sites, but it does mean that the removal policy might not be one
we can reach consensus about.

So until we reach consensus on the appropriate mechanisms for
reclaiming disk space, it is likely that the protocol will remain
neutral/silent on the issue.  Since the versioning protocol has no
normative statements of the form "the server MUST NOT delete ...", the
versioning protocol does not conflict with any such technique, and
therefore it raises no barrier to any such choices a server (or future
protocol version) choses to make.

   Solutions to problem 1 might involve something like a "orphaned
   resources report" that allowed the storage losses to be "found".

Such a report is reasonable (and we certainly will be providing a
custom report of this kind for my server), but since this report is
independent of the current feature set, I would not suggest holding up
standardizing on the current set of features in order to reach consensus
on the semantics and protocol for this report.

   2. Features which DeltaV has presented as "independent" are not.  Working
   Resource requires UPDATE and possibly workspaces.

There are five packages defined in the versioning protocol.
There is no package that provides the working resource feature
without the update feature, so in that sense, yes, the working
resource feature requires the update feature (and vica versa).

There is no package that provides both the working resource
feature and the workspace feature, so in no sense does the
working resource feature require the workspace feature.

   Solutions to problem 2 might involve defining a CHECKIN verb that
   includes the update functionality.  Or it might involve recombining
   the sections of DeltaV so that a server cannot advertise support
   for Working Resource if it does not support UPDATE and possibly
   workspaces.

A server is already told that it SHOULD support one of the defined packages,
and there is no package that has the working-resource feature
without the update feature).  We tried to strengthen that to a
MUST, but could not achieve consensus on that stronger statement.

   Please let me know when the conf call is and how to join.

I'll send out mail beginning of next week.  It should be the standard
number, but I just have to confirm with our IT organization that that
number is still reserved for us at that time.

Cheers,
Geoff

Received on Saturday, 23 June 2001 23:18:53 UTC