On Di, 2012-01-24 at 13:24 +0100, Mikel Astiz wrote:
> To get started quickly, a new backend could derive from the
> TrackingSyncSource and simply not implement any kind of change
> tracking and writing. In terms of the TrackingSyncSource API that
> means that the derived class provide a list of IDs without revision
> strings and only implements the item read method.
Thanks for the info. I'm going to do some tests following your
suggestion, but I already have some questions:
1. Assuming this backend needs to have D-Bus communication to another
daemon (obex-client), how would it access the mainloop in order to have
All backend calls are made outside of any event loop. They are allowed
to do whatever they want to get their work done and then return. So to
get access to a glib event loop you would set up your events, do a
g_main_loop_run() and once the work is done, return with
The downside is that asynchronous events like "the D-Bus server you want
to talk to died" will not be caught unless the backend is active.
2. For the non-supported backend functionality (particularly write
operations), what would be the proper thing to do? Just omit the calls?
I would throw an exception so that it is more visible when the function
happens to be called accidentally, for example when two-way sync is
configured although not supported.
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.