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). > > Yeah, though this seems like a lot of extra overhead, between > creating the entries, checking the entries, expiring the entries... > On the other hand, we already have code in place to exclude sending > changes to the client that were the result of changes DUE to the > client. E.g., changing a contact on the device still causes a history > entry to be created, but we must ignore that entry since the client > is the one who made the change in the first place. Perhaps if we need > to go this route, we could utilize the same system for this as well. > Again, I'm saying all of this without looking at code... > >> 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. > > Exactly. We would be exchanging one issue for another. > > >> Only a monotonic counter will solve this. Let's see if we can come up >> with a simpler solution... > > The more I think about it, I think my previous suggestion of either > having the history system increment the ts before writing it, or > activesync decrementing the end_ts before querying is the way to go. > There will still be a slight change of this still happening but if > the history system can't guarantee an entry is available within > something like 10 to 20 seconds of the time it is stamped with,than > there are bigger problems with the API itself here... >
Attachment
Watch this ticket

Saved Queries