RE: Submission: deltav subset

Lisa,

our server currently doesn't seem to support to make something unversioned
explicitly, nor do we feel that we need global properties. I guess this
makes our deltaV support "simpler" than yours :-)

And yes, we have thought about emulating a VHR, but didn't find a compelling
reason to do so.

Julian

> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Lisa Dusseault
> Sent: Tuesday, October 23, 2001 7:00 PM
> To: Julian Reschke; Stefan Eissing; Jim Amsden;
> ietf-dav-versioning@w3.org
> Subject: RE: Submission: deltav subset
>
>
> 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:35:45 UTC