Tickets :: Comment on [#12175] Add modification sequence support to Horde

* Your Email Address
* Spam protection	Enter the letters below: ..___..__..__ .__ \| \| \| \|[ __[__) \__\| \| \|__\|[_./\| \
Comment	>> The other possibility would be to somehow track the most recent >> history id detected. Though I really don't like this approach since >> it means the client code would need knowledge of how they history >> system functions - and it assumes any history backend would both have >> some unique entry identifier, and those identifiers are numeric (or >> at least increase in some numeric-like fashion). > > My idea of abusing the history_id as monotonic counter is doomed anway: > In the Kolab world, an object can disappear and re-appear. So a > history database entry with a low id might have a current timestamp > and therefore be missed again. > >> Both approaches would require some API changes to both the activesync >> code as well as the history code in order to provide the needed data >> - and such changes would need to maintain BC. > > It seems like a good idea to keep an array of seen object UIDs during > the last sync timestamp window (start_ts <= x <= end_ts). We would > also need to keep this list for every action (add, modify, delete). > > We can start expiring entries in this list once the current > "start_ts" is higher than the last noted end_ts. > > That still leaves one problem: If an object gets changed twice during > the same second and a client already saw the first change, it will > miss the second change. This risk is rather low but it will happen > sooner or later. > > Only a monotonic counter will solve this. Let's see if we can come up > with a simpler solution... >
Attachment
Watch this ticket

Saved Queries