[Tickets #11590] Re: Kolab backend: IMAP cache does not get updated

[bugs at horde.org]

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

Ticket URL: http://bugs.horde.org/ticket/11590
------------------------------------------------------------------------------
  Ticket             | 11590
  Updated By         | Gunnar Wrobel <wrobel at horde.org>
  Summary            | Kolab backend: IMAP cache does not get updated
  Queue              | Horde Framework Packages
  Version            | Git master
  Type               | Bug
  State              | Assigned
  Priority           | 3. High
  Milestone          |
  Patch              |
  Owners             | Gunnar Wrobel
------------------------------------------------------------------------------


Gunnar Wrobel <wrobel at horde.org> (2012-10-31 19:34) wrote:

>> I lack a final plan concerning the synchronization strategy. The
>> problem with the synchronization is that each list synchronization
>> costs two IMAP calls (LIST and METADATA) and each data
>> synchronization as well (STATUS and SEARCH - the latter identifies
>> deleted messages).
>
> Any reason you are not using CONDSTORE/QRESYNC if it is available?

No. I planned to use these but never found the time to actually get  
into this and write the necessary code. What you write sounds however  
as if this would avoid even more IMAP calls than I expected. My  
assumption was that CONDSTORE would allow me to reduce the two IMAP  
calls in each situation to a single one. If there is even more to be  
gained here then this makes implementing this even more attractive.

> QRESYNC solves the last issue entirely (and CONDSTORE solves the  
> last issue transparently within the Imap driver).  However, a cache  
> backend is needed to use these.
>
> Given the activesync may use MODSEQs also without using a cache  
> driver, it may be useful to allow a MODSEQ to be explicitly given to  
> the openMailbox command.  Although this has major drawbacks, since  
> openMailbox() is called extensively within the IMAP driver itself so  
> a mailbox may already be open by the time a MODSEQ can be provided.
>
> A better option might be to create a custom cache driver to pass to  
> the IMAP driver.