RE: Resolving outstanding issues in DeltaV

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".

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.

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

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

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.

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

Lisa

> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Clemm, Geoff
> Sent: Friday, June 22, 2001 3:13 PM
> To: ietf-dav-versioning@w3.org
> Subject: Resolving outstanding issues in DeltaV
>
>
> My current approach, unless guided otherwise by our working
> group chair, is to only make changes to the protocol if there
> is consensus that the change should be made.  Currently,
> I do not see consensus on either the resourcetype issue, or
> the working resource checkin issue (note: this means that
> the current DAV:resourcetype values in the protocol stay in).
>
> Since I believe that neither of these issues represent a critical flaw in
> the protocol (but rather represent possibly useful extensions
> that we could add in later), I propose that we table the issues
> for now.
>
> Would anyone like to take these topics to our Friday noon
> conference call?  It is possible that we could make more
> progress with that higher bandwidth medium.  In any case,
> we will discuss them at the DeltaV working group meeting
> in London.
>
> Cheers,
> Geoff
>
> -----Original Message-----
> From: Eric Sedlar [mailto:Eric.Sedlar@oracle.com]
> Sent: Friday, June 22, 2001 11:07 AM
> To: ietf-dav-versioning@w3.org
> Subject: RE: Dav:resourcetype
>
>
> I don't think we are getting close to a consensus on this issue.  I'm
> personally in favor of using dav:resourcetype for type information
> (after Yaron used his Jedi mind tricks on me), but I don't care enough
> to argue about it anymore.
>
> Is there a defined IETF procedure for flipping a coin to decide on what
> to do with a spec, or some other source of randomness?  How about if
> everybody agrees that if the Dow is an even number on Monday (at the
> close, truncating fractional part) we will put type information in
> dav:resourcetype, and if it is an odd number,
> we will use supported-*-resource-set (and go back to <dav:is-principal>
> in the ACL spec)?
>
> Deal?  Geoff?
>
> (P.S.  I have a suggested topic as an alternative for those who want to
> argue about this more:  Is operator overloading in C++ a good idea or
> not?  Discuss.)
>
> --Eric

Received on Friday, 22 June 2001 18:32:20 UTC