On Di, 2012-01-24 at 13:24 +0100, Mikel Astiz wrote: > Hi Patrick, > > > 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 > pseudo-blocking calls?
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 g_main_loop_quit(). 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. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
