Julian Foad <julianf...@btopenworld.com> writes: > Philip Martin wrote:
>> [Conceivably >> the RA implementation of the current Ev2 API could deltify the list sent >> back by caching the list received but that's horrible and doesn't solve >> the problem of getting the list in the first place.] > Why is this different from the delta-transmission of file content? > The principle of Ev2 is to describe changes in terms of "the new state > is Y" at the API level, and to leave deltification to be arranged > between the producer implementation and the consumer implementation. > Why cannot properties be handled this way, and why cannot (or should > not) children-lists be handled this way? For this operation svn cp http://host/repo/trunk ^/branches/foo I don't see how to avoid the having the server transmit the existing children-list to the client. Ev2 has introduced that inefficiency. I can see that with caching we could implement some sort of delta for sending the children-list back to the server, but even that looks ugly. Does the RA layer cache every children-list received? Does the client provide a callback for the RA layer to cache and retrieve children-lists. A cheap branch operation which transfers a few dozen bytes in Ev1 (plus a few thousand bytes for HTTP headers) will have to transfer Megabytes with Ev2. -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
