RE: Submission: deltav subset

We struggled since the beginning of DeltaV trying to determine THE minimal 
subset everyone would build. No matter how we sliced it, someone wasn't 
happy, so we'd slice it again. This consumed many hours in the design and 
working group meetings and many mailing list submissions, and it looks 
like we're not done yet. 

The current spec addresses this problem the best way we could. It 
specifies extremely minimal core versioning semantics that must be 
supported by all DeltaV compliant servers, a number of optional features, 
and a set of recommended packages of features to provide functionality 
consistent with common practice. This was an attempt to strike a balance 
between flexible implementation options for server writers with the need 
to minimize client complexity and encourage interoperability. We realize 
the core versioning features are generally insufficient for any production 
versioning server, and some optional features must be implemented. The 
packages are our best effort at coming up with useful feature sets. If 
these prove to be either wrong or insufficient in practice, then we should 
change them as part of the natural evolution of the spec.

However, I think it is important to work with what we have before 
introducing a lot of new packages. Taken to its logical extreme, we'd have 
one package per server vendor. This isn't necessarily bad, but it will 
complicate clients and inhibit interoperability. So I would encourage all 
server writers to 1) focus first on the clients you expect to support, 
their use cases and required features. 2) Pick a package from the DeltaV 
spec that best meets you client needs. 3) Implement as much as you can 
from the package, and return error conditions for specific things you 
can't support in such a way that clients can make requests consistent with 
the package, and get reasonable feedback from a server that can't do them 
at the moment. 4) over time, address the features you don't fully support, 
and consider adding additional features to support other packages so you 
can better support more clients.





"Julian Reschke" <julian.reschke@greenbytes.de>
10/23/2001 08:00 AM

 
        To:     "Stefan Eissing" <stefan.eissing@greenbytes.de>, "Lisa Dusseault" 
<lisa@xythos.com>, "Jim Amsden" <jamsden@us.ibm.com>, 
<ietf-dav-versioning@w3.org>
        cc: 
        Subject:        RE: Submission: deltav subset

 

I have my doubts that defining a common subset of DeltaV that makes sense 
to
a big group of people is achievable (I remember similar discussions in
xml-dev about removing "unnecessary" features from XML: everybody agreed
that there are some, but it wasn't possible to agree about *which* were
unnecessary).

In particular, Lisa's proposal says that a server MUST support the
version-history feature. Ours doesn't (and can't be easily changed to
support it). Yet, information about the existing versions can be retrieved
using REPORT, so *I* would argue this is an unnecessary feature :-).

That said, it is certainly a good thing to publish detailed information
about specific deltaV implementations (and their recommended usage).
However, I'm not so sure that this belongs into an Internet Draft.

Julian

> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Stefan Eissing
> Sent: Tuesday, October 23, 2001 10:11 AM
> To: Lisa Dusseault; Jim Amsden; ietf-dav-versioning@w3.org
> Subject: RE: Submission: deltav subset
>
>
> I think the definition of this deltav subset is very much needed
> and that Lisa has made a very good start with it. To be more specific:
>
> - Our server falls (from deltav point of view) into the same group
>   as sharemation does: linear versioning on resources, no versioning
>   on collections. There is definitly a need for such servers.
> - DeltaV is so rich (and for good reasons) that as an implementor
>   you have to make quite a lot of choices. The definition of a subset
>   would give guidance in this process and ensure interoperability.
>   Without such a definition, I see interworking between deltav
>   servers and clients as a much longer and more painful process
>   than it needs to be.
>
> //Stefan
>
> > From: ietf-dav-versioning-request@w3.org
> > [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Lisa Dusseault
> >
> > I'll explain some of the background to this message, since I started 
the
> > thread below its cc' list was expanded.  Initially, I asked Jim
> > Amsden if he
> > wanted a new deltav-related internet-draft to be a working group
> > draft or an
> > individual submission.  This explains the history and reasons
> > behind the new
> > internet-draft...
> >
> > I've talked to various people in the last few months, both
> those involved
> > directly in the DeltaV WG and those mostly involved in WebDAV but
> > keeping an
> > eye on DeltaV.  A common theme has been some uncertainty what features
> > should be implemented for simple versioning, in software not
> intended for
> > source control but just for web authoring or document management.  The
> > existing packages defined in DeltaV are a good start, but there's
> > still lot
> > of possible variation in how to implement a DeltaV server or client 
even
> > once a package has been chosen.
> >
> > Thus, I've been working on a document to make it easier for
> simple WebDAV
> > authoring clients to implement DeltaV, by selecting a number of
> > features and
> > a number of simplifications that a server can make.  If a server
> > advertises
> > these simplifications, then the client's job is much easier (the 
client
> > won't have to worry about forking, multiple checkouts, older versions
> > getting checked out, or older versions being targetted).  Both
> the server
> > and the client can still be DeltaV compatible.
> >
> > I've posted the initial draft on
> > http://www.sharemation.com/~milele/public/dav, and it should soon be
> > available on the IETF site as well.  I'm very much interested in 
hearing
> > comments, suggestions, etc.  Much thanks to Peter Raymond, Alan Kent 
and
> > Mark Hale for their initial comments.
> >
> > Lisa
> >
> > -----Original Message-----
> > From: ietf-dav-versioning-request@w3.org
> > [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Jim Amsden
> > Sent: October 18, 2001 4:35 PM
> > To: ietf-dav-versioning@w3.org
> > Subject: RE: Submission: deltav subset
> >
> >
> >
> > I'm inclined to declare victory on our DeltaV charter and let
> some servers
> > get built on what we have before we start making a lot of
> > immediate changes.
> > Of course I would welcome any BOF to determine level of interest in
> > extensions, new packages, etc. DeltaV is now firmly on the
> > standards track.
> > The next step is to get some implementation and determine
> interoperability
> > issues. If the community fragments immediately on different
> packages that
> > aren't interoperable in meaningful ways, then certainly that's good
> > information for the standards process that would need to be
> > addressed. But I
> > think the community would benefit from attempting to implement
> the spec as
> > written so we encourage interoperability.
> >
> > As for shutting down DeltaV, we're only at proposed standard. We could
> > consider updating the charter to move to the next stage in the
> > lifecycle. I
> > would be happy to entertain suggestions as to the content of such
> > a charter,
> > and if there's sufficient interest, we can propose the next set of 
work
> > items to the AD's as either continuation of DeltaV (with a new
> > charter), or
> > other working groups focused on more specific tasks.
> >
> >
> >
> > "Jim Whitehead" <ejw@cse.ucsc.edu>
> > 10/18/2001 06:36 PM
> >
> >         To:        "Clemm, Geoff" <gclemm@rational.com>, "'Lisa
> > Dusseault'"
> > <lisa@xythos.com>, "Jim Amsden" <jamsden@us.ibm.com>
> >         cc:
> >         Subject:        RE: Submission: deltav subset
> >
> >
> >
> >
> >
> > Geoff Clemm writes:
> > > I think it is more appropriate to keep it as an
> > > individual submission until the working group has had
> > > a chance to review/iterate on it.
> >
> > This may be true, but IETF policy does say that it is the Chair's
> > discretion
> > on whether a document is a WG draft or an individual submission.
> >
> > I was just pointing out that Jim may cause friction with the ADs if, 
by
> > making a new WG draft, he extends the life of DeltaV when they
> think it's
> > close to being shut down. I imagine they are keen to avoid
> another WebDAV
> > :-)
> >
> > But, even if Jim does decide that it should not be a new draft,
> > it would be
> > well within Lisa's rights to hold a BOF at the next IETF with an
> > eye towards
> > creating a new WG, "SDV" (simple Delta V), say.
> >
> > - Jim
> >
> >
> >
>
>
>
>

Received on Tuesday, 23 October 2001 09:04:07 UTC