- From: Roy Seto <Roy.Seto@oracle.com>
- Date: Wed, 03 Oct 2001 13:31:41 -0700
- 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. Roy "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