>> 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
>
Received on 2014-02-14 14:18:58 CET