On Thu, 2009-10-22 at 09:25 +0100, Sascha Peilicke wrote:
as Patrick revealed to me yesterday, the SyncEvolution project is not
currently to commit to a stable API/ABI policy. Patrick pointed out that this
is particularly difficult to do right in C++.
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.
This is perfectly ok for now,
but might become more important in the future of SyncEvolution, when adoption
in other projects increases (such as KDE PIM at the moment).
Point taken. Once SyncEvolution stabilizes a bit more and desired usages
of it become clearer, we can and should revisit this topic.
I'd like to point you guys to a document the KDE project set up a
ago which shows typical issues and provides some solutions . Especially the
d-pointer (or opaque pointer) pattern should be applied to all classes that
are part of the public API .
These are good references. No big surprises, but nice to have it written
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.