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

* Your Email Address
* Spam protection	Enter the letters below: . ..__..___.__ __. \| \|\| \|[__ [__)(__ \|/\\|\|__\[___\| \.__)
Comment	>> Also this is duplicate functionality to timestamps which are >> essentially a numerically incrementing value. I think the correct way >> to fix this would be to ensure that entries are guaranteed available >> by the timestamp that it is recorded with. Maybe some "fudge factor" >> added to the timestamp before it is written by the history system to >> be sure it's in the future? A second choice, if this is not desired >> for some reason, would be to decrement the end_ts by some fudge >> factor to ensure any newly written changes are not occurring in the >> currently queried slice of time. > > Again, the same idea occurred to me while discussing this with a colleague: > > We lower the current sync timestamp by -1 and this ensures > we only pick up changes that are done (the past is the past). > (except for clock skews on the server...) > > Then we just need to make sure we get the interval window right ('>' > vs. '>=') > so we don't pick up entries twice. Since we can't modify the getChanges() > API behavior of the horde apps, we need to +1 or -1 in the ActiveSync module. > > Done right, the change itself would be rather small. >
Attachment
Watch this ticket