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

Flag making DAV:response elements of UPDATE and MERGE optional

From: Roy Seto <Roy.Seto@oracle.com>
Date: Wed, 03 Oct 2001 13:31:41 -0700
Message-ID: <3BBB75AD.3D45D4E@oracle.com>
To: ietf-dav-versioning@w3.org
No, I don't have performance numbers to substantiate this
concern at this point. 

If the extension is added later, there might be a tradeoff
between simplicity and compatibility with the Proposed
Standard RFC. I think the simplest semantics would default
to not returning the DAV:response elements (in other words,
a DAV:return-response flag is simpler than a
DAV:omit-response flag). Also, I think clients should
explicitly ask for the extra response information if they
include cache maintenance logic to use it. On the other
hand, making the default return the DAV:response elements
would preserve the most compatibility with implementations
of spec as it stands in draft-18.

I think these obstacles can be overcome if necessary.


"Clemm, Geoff" wrote:
>    From: Roy Seto [mailto:roy.seto@oracle.com]
>    - Merge and update features: Add a flag to make DAV:response
>      elements of UPDATE optional, and to make DAV:response elements of
>      MERGE optional for targets modified by postcondition
>      DAV:descendant-version. Use case: improve response times when the
>      request-URL of the MERGE or UPDATE has an extremely large number
>      of members whose DAV:checked-in versions are modified by the
>      MERGE or UPDATE, and when the client's caching policy will not
>      benefit from the DAV:response elements enough to outweigh the
>      cost of adding the DAV:response elements to the response body.
> A server has to compute all of this information anyway (to do the
> update), so all one would be saving would be the cost of sending the
> info back (which is rather small chunk of information, compared to
> what the net is set up to pass around).  But if this really turns out
> to be an issue in practice, it certainly would be easy to add such an
> extension.  Are you getting actual performance numbers on this that
> concern you?
Received on Wednesday, 3 October 2001 16:27:51 UTC

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