Now I am having worries about the algorithm here. There are multiple scenarios, and just want to make sure that I am covering them all.
Ignoring markers..., these are the scenarios I can see:
- cached context identical to app context
- cached context same length as app context but content is different
- cached context is shorter than app context, but content is same as far as it goes
- cached context is shorter than app context, but content is different
- cached context is longer than app context, but content is same as far as it goes
- cached context is longer than app context, but content is different.
I think those are the only 6 scenarios. What do we want to do for each one?
- unchanged
- changed, set cache to app context
- lengthen to app context, but keep markers, consider unchanged?
- changed, set cache to app context
- shorten to app context, but keep markers, consider unchanged? or changed + set to app context?
- changed, set cache to app context
We have to consider the rolling buffer that we'll have as we add new content, and that will impact whether or not the app context is longer than cache (remembering that the cached context may have markers which will shorten the overall non-marker content of it).
So number 3 and number 5 6 need careful consideration.
Relates to #10098.
Now I am having worries about the algorithm here. There are multiple scenarios, and just want to make sure that I am covering them all.
Ignoring markers..., these are the scenarios I can see:
I think those are the only 6 scenarios. What do we want to do for each one?
We have to consider the rolling buffer that we'll have as we add new content, and that will impact whether or not the app context is longer than cache (remembering that the cached context may have markers which will shorten the overall non-marker content of it).
So number 3 and number 5
6need careful consideration.Relates to #10098.