Hello! For 1.0, we hope to add automatic syncing. Part of that effort is to make starting and running a sync cheaper a) by not dumping databases unless the SyncML session really runs b) reducing the amount of calls into the underlying database
This is tracked as: http://bugzilla.moblin.org/show_bug.cgi?id=7708 Regardless whether we go ahead with automatic syncing, these optimizations are worthwhile on their own. Point b) is something that Franz explicitly asked about once. But they depend on an API change, so let me bring that up here. Are the proposed changes that I currently have pending in my "pohly" branch in the git repo on moblin.org okay? Ove, Franz, your backends should continue to compile and work, but they don't completely support the new "preventSlowSync" feature. It will always be on, even in the one case where a slow sync is acceptable (empty local database). Instead of repeating myself, let me quote the commit messages here. For diffs (if necessary) consult the repo: commit 33f6e2064c7fc7c376336e86fd9460df3cdbf14c Author: Patrick Ohly <[email protected]> Date: Tue Feb 16 17:43:41 2010 +0100 SyncSourceRevisions: cache result of listAllItems() (MB #7708) When automatic backups are enabled (the default), SyncSourceRevisions and derived classes like TrackingSyncSource called listAllItems() twice, once during backup and once while checking for changes. This patch introduces caching of the result returned by the first call. During a normal session, that will be during backup, with change detection reusing the information. If backups are off, the call will happen during change detection, as before. The advantages of this change are: - more efficient, in particular for sources where listAllItems() is slow - avoids a race condition (backup stores one set of items, changes are made, change detection works with another set) That race condition is both fairly theoretical (short time window) and had no impact on the correctness of the sync, only on the output (data comparison would not show all changes synced later). Now the race condition still exists if changes are made while a sync runs, which is the bigger problem that still needs to be solved (for EDS, see MB #3479). Restoring data also calls listAllItems(). It does not use the cached information, just in case that it is to be called more than once per instance, and because there is no benefit. commit 5f18644fbfc944db1759dbb726f2ea8b7892e0cf Author: Patrick Ohly <[email protected]> Date: Tue Feb 16 20:11:16 2010 +0100 SyncSource API: added m_isEmpty operation (MB #7708) The current solution of checking for empty sources by looking at the "before" database dump is a hack which fails if creating that backup was disabled. It also prevents delaying the dump until after the start of the session, because the information must be available before starting the session, so that the XML config can be created with slow sync check enabled if needed. This patch adds a new operation which backends must implement if they want to provide the "is empty" information for the slow sync detection. This is optional. If the information is not available, slow sync detection is always on, even when not strictly needed. commit fc059f7017f32b9184b5781a875a3ab22ca0c0c5 Author: Patrick Ohly <[email protected]> Date: Tue Feb 16 20:15:50 2010 +0100 SQLite backend: implement m_isEmpty operation (MB #7708) This patch demonstrates how the operation can be implemented by sources implementing the operations themselves. The implementation of SQLiteContactSource::isEmpty() might not be perfect, but it should get the job done. commit 9e45cb0c56e9975637214f0f03add823171b314c Author: Patrick Ohly <[email protected]> Date: Tue Feb 16 20:17:36 2010 +0100 TrackingSyncSource: added isEmpty() pure virtual method (MB #7708) This implements the new m_isEmpty operation with a pure virtual TrackingSyncSource::isEmpty() callback. It follows the philosophy that TrackingSyncSource should a) hide the underlying operation mechanism and b) prevent derived classes from compiling unless they do everything that is expected of them. All of the in-tree backends were adapted so that they provide at least a dummy implementation of the call, to keep them in a usable state. The file backend implementation is okay. The Evolution backends get the job done correctly, but not efficiently. Maemo and XMLRPC backends always return false, which is acceptable but should be changed (disables the "allow slow sync for empty databases" heuristic). commit 4713aa435afa8e51b18780f94595e81eead6008c Author: Patrick Ohly <[email protected]> Date: Tue Feb 16 17:15:46 2010 +0100 database comparison: also delay it in clients (MB #7708) Delaying the database comparison was done initially for servers to limit it to the sources really used by the client. In a client the same delay makes sense for syncs which fail because the peer cannot be reached. It is possible to delay the dump because starting the session no longer depends on it thanks to the m_isEmpty() operation. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
