W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > January to March 2002

RE: Selective propagation of changes

From: Clemm, Geoff <gclemm@rational.com>
Date: Wed, 13 Feb 2002 12:12:08 -0500
Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8AFA5@SUS-MA1IT01>
To: "Ietf-Dav-Versioning (E-mail)" <ietf-dav-versioning@w3.org>
I think it is worth making part of the standard.

But since only a few servers support this kind of DELTA
capability (but there definitely are some),
so it was lower priority than the MERGE functionality,
and didn't make it into the final "what we include in the
first version" cut.  There are other things, like "variants",
that are in the same category.

If anyone has the time to write up the DELTA proposal,
that would be great (we would post it to the "proposed extensions"
section of the DeltaV site).


> -----Original Message-----
> From: Clemm, Geoff [mailto:gclemm@rational.com]
> I would suggest the method name DELTA, and if you want to be fully
> general, it would take a list of "add" activities (i.e. those whose
> deltas you want to add) and a list of "subtract" activities
> (i.e. those deltas you want to remove).
> Unlike MERGE (which only performs a checkout if the versions are
> on different lines of descent), DELTA will always checkout the
> target, and will always have the server compute the results of
> adding/deleting the specified deltas (i.e. that's the whole point
> of the DELTA request).
> Note that a MERGE of an activity (which effectively merges an 
> entire line of descent) is very different from a DELTA of an
> activity (which only applies the differences captured by an activity).

That sounds good. Only it would be propriatry for the server that invents
this. What do you think, is this a feature that is worth of being part of
the DeltaV? Was this in discussion yet and skip due to some reason?
I don't like the propriatry thing that much. But if its not worth of being
part of the standard, so it is and then its proprietary.
Received on Wednesday, 13 February 2002 12:15:18 UTC

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