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.
>
>
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution

Reply via email to