Patrick, all,
Here's my first stab at adding support for obex 0.47 support to the
pbap backend. It does handle CreateSession and calls PullAll passing
in a temporary file based on the mac address of the phone, however I'm
getting an exception in gdbus-cxx-bridge like this:
[ERROR] unexpected exception caught in dbusCallback(): g_variant
failure ./src/gdbusxx/gdbus-cxx-bridge.h:1393
Trace/breakpoint trap
I tried changing the properties type in pullAllCbNew from Params to
DBusArray in case it was not understanding how to convert a std::map
from a dbus a{sv} but that didn't make a difference. Is there
something I'm obviously missing here? I'll look into creating the
transfer signal watcher tomorrow, but if I can't get PullAll's
callback to get called I'm a bit stuck.thanks, Jeremy On Tue, Aug 21, 2012 at 10:59 AM, Jeremy Whiting <[email protected]> wrote: > On Tue, Aug 21, 2012 at 12:37 AM, Patrick Ohly <[email protected]> wrote: >> On Mon, 2012-08-20 at 19:31 -0600, Jeremy Whiting wrote: >>> 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: >> ^^^^^^^^^^^ >> Typo - the name of the config is target-config@pbap, if you followed the >> README. > > Of course, my bad. Not sure how I messed that up repeatedly, but it's > sorted out now. > >> >>> 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 >> ^^^^^^^^^^^^^ >> >>> 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). >> >> I would do a runtime check. The result of PbapSession::pullAllCb() could >> be a pointer into memory (obexd < 0.47) or a memory-mapped file (obexd >>>= 0.47). Then the rest of the code then needs to be changed to work >> with plain char pointers for the buffer instead of the current const >> std::string, but would be the same for both versions. > > Ok, when PbapSession is constructed it creates the m_client which > needs to connect to either org.openobex.client or > org.bluez.obex.client, for a runtime check I could try the new > address, then fall back to the old one if the new one fails, right? > If you had some other kind of runtime check let me know. Then I can > store in the PbapSession class which interface to use and if else all > the code that needs to act differently depending on the obex version. > > thanks, > Jeremy > >> >>> > 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? >> >> You'll have to access the file. The Transfer object only gives you meta >> information about the file. >> >> You can set up operations in this order: >> 1. Create temporary file. >> 2. Create a SignalWatch for all object paths which updates status >> if the Transfer's Filename matches the temporary file. >> 3. Start the transfer. >> 4. while ("still running") g_main_context_iteration(NULL, true); >> 5. mmap file >> 6. parse it >> >> -- >> 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. >> >>
0011-WIP-add-support-for-obex-0.47-to-pbap-backend.patch
Description: Binary data
_______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
