[Tickets #11590] Re: Kolab backend: IMAP cache does not get updated
bugs at horde.org
bugs at horde.org
Wed Oct 31 18:34:35 UTC 2012
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 18:34) wrote:
This is currently the expected behavior as the implemented
synchronization strategy is pretty dumb. The old code had no
synchronization strategy and so it always synchronized the data on
access. You should be able to go back to the old behavior by modifying
Horde/Kolab/Storage/Synchronization.php. Add a "if (false && ..." to
both conditionals present in that file. Does that revert back to the
expected behavior?
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).
Doing this type of synchronization with each and every data access
keeps the data in sync always. But of course it is a performance drag.
Especially if you build the calendar and have access to ten or twenty
different folders. And most of the times this type of synchronization
is not really necessary. What describe - concurrent access with two
clients to the same folder - is not the default case after all. At
least not for personal folders.
At some point I wanted to create the "kolab" Horde application to
offer at least a "Sync now" button to provide the user with control
over the synchronization strategy. This would put the user into
control of the synchronization strategy, would avoid performance
issues but would not be an improvement of usability. Probably there
are better solutions.
Any suggestions?
More information about the bugs
mailing list