On Thu, 2009-10-22 at 09:25 +0100, Sascha Peilicke wrote: Indeed. It wasn't a goal so far, simply because there was no need. The code could have been written differently from the start, but wasn't because Funambol's C++ library isn't ABI stable either. So to clarify, the intended use right now is: * Take the source code and compile it into your own distribution, for example as a SyncML client for another platform. We try to minimize API changes, but it is not frozen. The class renaming and introduction of the "SyncEvo" namespace for 0.9.1 was a lot more intrusive than what will come in the future and was done now with the hope that it happens in time before more people start using the code. * Write backends that can be plugged into SyncEvolution without recompiling it. Hindered somewhat by not guaranteeing a stable ABI :-/ However, SyncSource and its derived classes is better in that regard than the GUI classes. * Use the new SyncEvolution 1.0 D-Bus API in front ends. In contrast to the corresponding C++ classes, the D-Bus API is under much better change control. Point taken. Once SyncEvolution stabilizes a bit more and desired usages of it become clearer, we can and should revisit this topic. These are good references. No big surprises, but nice to have it written down ;-) One point we wondered about was the dependency on Boost::function instances in the SyncSource API. The whole "compose an implementation from different parts" depends on this. On the one hand, Boost::function should be very stable and not change its size. On the other hand, we don't control the implementation and thus cannot be sure of that. -- 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.