Tickets :: Comment on [#13747] Speed up ActiveSync synchronisation handling

* Your Email Address
* Spam protection	Enter the letters below: .___.. ..___..__..__. \| \|\ \| \| \| \|\| \| \| \| \\| \| \|__\|\|__\
Comment	> >> 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. >
Attachment
Watch this ticket

Saved Queries