7:59 a.m.
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 <patrick.ohly(a)intel.com>
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 <patrick.ohly(a)intel.com>
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 <patrick.ohly(a)intel.com>
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 <patrick.ohly(a)intel.com>
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 <patrick.ohly(a)intel.com>
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.