Hello!
I've picked up work on the PBAP backend [1] again. The "pbap" branch can
be merged with current master without problems and works as it did
before with obexd < 0.47 (see the src/backends/pbap/README):
* "refresh-from-remote" works.
* The entire phone address book, including PHOTOs, is downloaded
in each sync.
There are several todos for the code:
1. Adapt to obexd >= 0.47 and the new D-Bus API in it; the current
code no longer works.
2. Support incremental sync - somehow.
3. Remove overhead for syncing: don't write anything to disc if
nothing changed.
4. First copy contacts without PHOTO data, then add PHOTO data.
I'd like to tackle points 2 and 3 first. For incremental syncing, there
are three options:
A. The PBAP source could create a key for each contact based on
some property (currently done based on N) and a revision string
by hashing the vcard content (not done at the moment). Change
tracking would be done by the TrackingSyncSource. The downside
of this is that the TrackingSyncSource will get confused when
sending contacts sometimes with and sometimes without PHOTO
data.
B. Assemble a custom sync source which does its own change tracking
instead of relying on TrackingSyncSource, and use hashing to
detect changes.
C. Don't try to do change detection in the source at all. Instead
do a slow sync that doesn't write to the phone, let the
Synthesis engine do its normal matching in the first cycle
(without PHOTOs), remove local contacts which were not matched,
then do a second cycle to add PHOTO data.
These options are not mutually exclusive. Option C is needed if syncing
failed, because without it, a "refresh-from-remote" would be needed to
recover. Such a "refresh-from-remote" would wipe out all local data,
even those contacts which were not changed, which is undesirable (want
to reduce disk writes). A normal slow sync would leave deleted contacts
around.
Therefore I'll investigate that option first.
About obexd: compatibility with old obexd needs to be preserved for a
while, because Tizen uses obexd 0.44 and I don't know if or when it can
be updated. It's also convenient (some distros like Debian Testing do
not have 0.47 yet). Note that the new obexd API uses a temporary file to
transfer. Those files should be created in the system temp dir where
they can be garbage collected. Reliably detecting transfer completion
depends on listening to signals in advance - see [2].
In SyncEvolution, listening to D-Bus signals is done with the custom
GDBusCXX::SignalWatch template class. Documentation of that C++ D-Bus
binding is admittedly weak. Grep the source to find examples how it is
used and/or let me know if you want better documentation of the C++
wrapper and I'll add it.
[1] Previous discussions:
http://www.mail-archive.com/[email protected]/msg03148.html
http://www.mail-archive.com/[email protected]/msg03167.html
[2] http://thread.gmane.org/gmane.linux.bluez.kernel/28481
--
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
