Your write up seems basically accurate to me. I would note again that reading the earliest Doc of an alternate is an historical artifact of the implementation and not at all a functional requirement.
The other half of the proposal is that, when servicing a range request that has been forwarded to the origin server, we cache fill any complete chunks that are returned and ignore any partial chunks. This is the point of having chunks, to make it much more likely that we can capture data from range requests. We could do that with just fragments but IMHO the granularity of that is too coarse. It might be interesting as a first step to try it to validate the partial write logic. There is also the issue of how much compile time and/or run time control should be provided over the graininess of the chunks. IMHO it would be reasonable to support compile time control over a value N such that each fragment consists of 2^N chunks. The fragment tables changes are now on trunk, committed under the TS-1339 bug ID. P.S. An alternative scheme would be to store for each fragment store a valid span (two values, start/end) and then extend that if a range request has an overlap. You could even, in the disjoint case, compute which span had more data and keep that (e.g., effectively discard cached data if you can replace it with a larger span in the fragment). Sunday, September 9, 2012, 5:37:29 PM, you wrote: > Thank you very much for the clarifications! > I think now I have a better view on the current cache structure and your > proposal. > Who should also validate these changes before going to the next step which > I think would be the strategy of what and when to cache? > PS: is there a branch already available with your change to move the > fragment table from the first Doc to the alternate entries?
