Patrick, On Fri, Aug 17, 2012 at 5:46 AM, Patrick Ohly <[email protected]> wrote: > 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.
In order to tackle this task, I've gotten the pbap branch, rebased it on master and gotten it to build by changing all the method() calls to method.start(). However the guide in the src/backends/pbap/README no longer works and gives the following message when I run syncevolution --print-items test-config@pbap: [ERROR] backend not supported by any of the backend modules (...) or not correctly configured (backend=select backend databaseFormat= syncFormat=) [ERROR] configuration 'test-config@pbap' does not exist though I did set up test-config@pbap (and it appears in --print-configs) with: syncevolution --configure syncURL= addressbook/backend=pbap addressbook/database=obex-bt://$MYMAC target-config@pbap addressbook I do have a recent libsynthesis installed that it's building against. Also how would you suggest compatibility with obex 0.47 and obex < 0.47 work? separate branches? separate code paths in the same branch (maybe with a check to see if org.openobex.client or org.bluez.obex.client is implemented to know which path to take). > 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. In order to do this I just need to create a SignalWatch on Transfer and copy the file? or get the data from the Transfer object? thanks, Jeremy > > [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
