Hi Patrick,
> 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.
>
> > 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.
You have method signature changes in CreateSession(), so I would suggest you do
the runtime check exactly there. You should first try the 0.47-style call and
if it fails fall back to the old signature.
> > > 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.
Is there any particular reason not to let obex-client create the temporary file?
> 2. Create a SignalWatch for all object paths which updates status
A possible optimization here would be using path prefixes, so you can focus on
transfers belonging to your own session.
> if the Transfer's Filename matches the temporary file.
I'd rather check the object path instead of the filename (of course you need to
start the transfer first).
> 3. Start the transfer.
> 4. while ("still running") g_main_context_iteration(NULL, true);
> 5. mmap file
> 6. parse it
Cheers,
Mikel
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
