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

Re: The version element and workspaces

From: Werner Donné <werner.donne@re.be>
Date: Tue, 11 Apr 2006 13:46:07 +0200
Message-ID: <443B96FF.80200@re.be>
To: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Cc: ietf-dav-versioning@w3.org

If new clients should work with older servers there should be
a mechanism for a client to detect the compliance level of the
server. It can then act accordingly. In RFC 2518 the DAV header
seems to be used for this. I don't find such a mechanism in
RFC 3253.



Geoffrey M Clemm wrote:
> 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.

Werner Donné  --  Re
Engelbeekstraat 8
B-3300 Tienen
tel: (+32) 486 425803	e-mail: werner.donne@re.be
Received on Monday, 10 April 2006 11:46:21 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:48 UTC