W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > April to June 2006

Re: The version element and workspaces

From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Mon, 3 Apr 2006 22:25:17 -0400
To: werner.donne@re.be
Cc: ietf-dav-versioning@w3.org
Message-ID: <OF87691E7A.6B9EACCB-ON85257141.00417B23-85257146.000D4AD2@us.ibm.com>
Any new addition to the specification will cause any client that uses
that addition to fail against older servers that were implemented 
before that addition was defined.  To avoid this kind of failure,
we do not introduce changes in revisions of the specification unless
the benefit provided by that feature outweighs the cost of those failures.

Cheers,
Geoff 

Werner Donné <werner.donne@re.be> wrote on 03/31/2006 06:50:00 AM:
> Geoffrey M Clemm wrote:
> > One would need to identify a significant interoperability or 
performance
> > problem in order for it to merit a revision to the specification. 
> > I don't think either would apply to this extension.
> 
> Neither interoperability nor performance have anything to do with it. 
The
> proposed extension doesn't break anything and if using a label in this
> context could present a performance problem, then it would too in the
> contexts where it is used now. It is only a matter of consistency. When
> the label feature is supported, labels can be used for version selection
> when a VCR is given, only not in all situations, for which I see no 
reason.
> 
> The use-case for workspaces is also very valid. When activities are 
supported
> and used for branching, it is common to define the start of a new branch
> based on a label instead of a physical version. Otherwise you can forget
> about more advanced configuration management practices.
> 
> Why would interoperability and performance problems be the only reason 
for
> a revision? This implies that the current feature set should be 
considered
> as perfect, because how did the current features make it into the 
> specification
> then? How does the revision process work?
> 
> Performance is a non-issue. There is nothing shocking in WedDAV that 
would
> cause performance problems by definition and I don't see why additions 
would.
> The implementation should be sofisticated enough or simply not implement 
a
> feature.
> 
> I agree that an extension shouldn't break interoperability, unless in a
> major upgrade. Note, however, that this is not the same as requiring
> that most existing implementations are able to implement it, because 
that
> would mean the specification is not leading but merely consolidating an
> existing state of affairs. WebDAV deserves to be more than window 
dressing
> of existing products.
Received on Tuesday, 4 April 2006 02:25:49 GMT

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