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

* Your Email Address
* Spam protection	Enter the letters below: . ,.___.__ ..__. \./ [__ \| \ \|\| \| \| \| \|__/\__\|\|__\|
Comment	>>>> - Adapt ActiveSync code >>>> - Store last seen sequence number for each device >>>> - Use new API::getChanges($last_seen_seq, null, true) API >>>> to collect the changes on the server >>> >>> This is a BC break. This would mean the new version of >>> Horde_ActiveSync would require a updated version of the groupware >>> apps. We can make the applications require newer versions of >>> libraries, but we can't do the opposite. >> >> Is there a usual route in horde how to work around this? >> >> Like checking the API version of an app or check if a function exists? > > No, not a version check, because the ActiveSync library knows nothing > about application names/versions etc... There is nothing preventing > it from being used against some other, non-horde, groupware stack. > >> An ugly kludge would be to add a function "has_sequence_support()" >> and check for that function name in Horde_ActiveSync. > > Generally speaking, this is the only possible solution, and is what > we normally do when it is absolutely necessary. I.e., can't wait > until the next major version number. The problem in this case is the > changes are going to need to be too spread out. Is it doable? > Probably, but it will be an ugly, invasive, error prone change: > > (1) Horde_ActiveSync will need to be extended to store (and use) the > new counter in addition to the lastsync timestamp for ping detection. > I.e., Horde_ActiveSync is responsible for storing the state data. > > 2) Horde_Core - which is where the getChanges() functionality lives - > will need to know about the new counter, and then need to know to > call the correct method in each individual application's APIs to > fetch changes. I.e., Horde_Core is responsible for reporting back > changes to the ActiveSync library from the various groupware apps. > > (3) Groupware apps - Each app will need to be extended to accept the > new counter in lieu of (or in addition to) the timestamp. > > To maintain BC, we need to ensure that upgrading (1) or (2) without > upgrading (3) does not cause anything to break. When upgrading (3), > we can always require newer versions of (1) and (2). The reverse is > not true. > > So, we'd need to add new methods to both > Horde_Core_ActiveSync_Driver, Horde_Core_ActiveSync_Connector and > EACH groupware application's API, and each library would need to > perform multiple is_callable() checks to sniff out what data to > present. What happens if somebody upgrades only Turba, for example, > and not Kronolith? We'd have a mix of timestamps and counters with no > real way for the AS library to know which we need to store/send. This > is a REALLY ugly solution. > >> That could be removed in 5.1 again. > > No, if this were implemented, it wouldn't be implemented until 5.1 - > and the extra method names and matching is_callable() checks would be > removed in 6.0. Though the more I think about what would be required > to do this correctly, waiting until 6.0 is really the best option. > > >
Attachment
Watch this ticket

Saved Queries