>> Can we think of a better way to design the API so that it returns the >> interesting data without all the redundancy? Basically I think we want to >> describe changes to mergeinfo, rather than raw mergeinfo. > > Marc, > > Perhaps a better way to ask the question is: Can I encourage you to write the > API that you want? You already designed a cache for the data. What is the > shape of the data > in your cache, and can the API get the data you want in the form you > want it, directly? We'd be glad to help implement it. Even if you start with > an API which simply iterates over a range of revisions, at least that would > allow for the possibility of improving the efficiency internally at various > layers.
Looks like our emails have crossed :) I'll dig into the cache code and will try to come back with a more detailed API suggestion soon. -Marc On 14.02.2014 14:09, Julian Foad wrote: > I (Julian Foad) wrote: > >> Can we think of a better way to design the API so that it returns the >> interesting data without all the redundancy? Basically I think we want to >> describe changes to mergeinfo, rather than raw mergeinfo. > > Marc, > > Perhaps a better way to ask the question is: Can I encourage you to write the > API that you want? You already designed a cache for the data. What is the > shape of the data > in your cache, and can the API get the data you want in the form you > want it, directly? We'd be glad to help implement it. Even if you start with > an API which simply iterates over a range of revisions, at least that would > allow for the possibility of improving the efficiency internally at various > layers. > > - Julian >
