[Tickets #13747] Re: Speed up ActiveSync synchronisation handling

[noreply at bugs.horde.org]

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

Ticket URL: https://bugs.horde.org/ticket/13747
------------------------------------------------------------------------------
  Ticket             | 13747
  Updated By         | Michael Rubinsky <mrubinsk at horde.org>
  Summary            | Speed up ActiveSync synchronisation handling
  Queue              | Synchronization
  Version            | Git master
  Type               | Enhancement
  State              | Assigned
  Priority           | 1. Low
  Milestone          |
  Patch              |
  Owners             | Michael Rubinsky
------------------------------------------------------------------------------


Michael Rubinsky <mrubinsk at horde.org> (2014-12-10 21:30) wrote:


> So there will be visible just the replied / forwarded state or  
> nothing at all like in OL2013 with ActiveSync?

Ah, right. I forgot OL2013 doesn't even support displaying externally  
changed message state anyway. Yes, though - if it is disabled, no  
information about the reply/forward state would be displayed on any  
client for emails replied/forwarded via IMP. If the EAS client  
supports looking at message flags to determine this, then at least the  
fact that it was replied to will be shown, but no details such as when.

> Is this header search done in SQL against IMAP?

No, it's an IMAP search command executed directly against the IMAP  
server (via Horde_Imap_Client).

>> This happens for EVERY mailbox that is synchronized, against every
>> Message-ID the maillog indicates has changed since we can't know if
>> the message is from the mailbox or not.  We can't really store the
>> mailbox name in the history log since it's possible the mailbox name
>> would change, or the message will be moved to a different mailbox  -
>> making all such lookups useless.
>
> About which "changes" are you speaking about?

"Maillog changes" only contain details about reply/forward state. We  
only check this when the client is asking for all server changes (a  
SYNC request - this does not happen during the more frequent PING  
requests which only ask IF there are changes). After checking the IMAP  
server for new/vanished messages (a very quick operation when MODSEQ  
is active) we then query IMP's maillog to look for messages that have  
had a reply state change and lookup the UID as described previously.

It happens also on
> doing some simple changes on 1 message?

When you send ANY change FROM the client (such as a change in read  
flag) it almost always triggers a SYNC request (this is client  
specific), so yes, sending a simple read flag change to the server  
could cause this behavior.