[Tickets #12175] Re: ActiveSync misses changes from history database

[noreply at bugs.horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/12175
------------------------------------------------------------------------------
  Ticket             | 12175
  Updated By         | Michael Rubinsky <mrubinsk at horde.org>
  Summary            | ActiveSync misses changes from history database
  Queue              | Synchronization
  Version            | Git master
  Type               | Bug
  State              | Feedback
  Priority           | 1. Low
  Milestone          |
  Patch              |
  Owners             | Michael Rubinsky
------------------------------------------------------------------------------


Michael Rubinsky <mrubinsk at horde.org> (2013-04-15 14:21) wrote:

>>> - 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.