W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > October to December 2001

RE: Submission: deltav subset

From: Lisa Dusseault <lisa@xythos.com>
Date: Tue, 23 Oct 2001 10:00:18 -0700
To: "Julian Reschke" <julian.reschke@greenbytes.de>, "Stefan Eissing" <stefan.eissing@greenbytes.de>, "Jim Amsden" <jamsden@us.ibm.com>, <ietf-dav-versioning@w3.org>
Message-ID: <HPELJFCBPHIPBEJDHKGKIEGLCPAA.lisa@xythos.com>
I have my doubts about whether selecting a common subset is achievable too,
but I think it's worth a try given all the feedback I've heard.

I debated about putting version history in, left it out tentatively then put
it in again at the end.  The final reasons I put it in were:
 - we support it (hey, it's somewhere to start, and we support it for the
following reasons)
 - the best way I've found so far to make something unversioned, besides
inventing a new syntax, is to support deleting the version history and have
the server clean up the VCR to become a regular resource
 - it's the only resource that can have custom properties that apply to all
versions -- global properties

So I have a bunch of questions for you then, and anybody else who's
interested:

 - Have you considered supporting version histories as "fake" resources?
They don't need to have their own regular URLs -- they could be given URLs
like http://foo/bar/vcr.doc?access=version-history.  They don't need storage
allocated for them.  All the server has to do is be able to pretend they
exist.  Forgive me if you've already thought along these lines, but after
all a specification is really about what's on the wire, not what's in the
code.

 - Do you think making something unversioned is not required in simple
linear versioning?
 - Do you think global properties are not required in simple linear
versioning?

 - If you think making something unversioned is required, but still don't
want to support version history resources, how would you propose going about
it?  Do you think it would be OK for "DeltaV-subset" to define new syntaxes?
(Well, at the very least, we'd then have to rename the specification!)  So
far, I've carefully avoided defining anything new so far other than the
OPTIONS string for deltav-subset.

Lisa

> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Julian Reschke
> Sent: October 23, 2001 5:01 AM
> To: Stefan Eissing; Lisa Dusseault; Jim Amsden;
> ietf-dav-versioning@w3.org
> 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 13:01:34 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:42 GMT