On Thu, 2009-10-22 at 09:25 +0100, Sascha Peilicke wrote:
> as Patrick revealed to me yesterday, the SyncEvolution project is not
> planning
> 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 long time
> ago which shows typical issues and provides some solutions [1]. Especially
> the
> d-pointer (or opaque pointer) pattern should be applied to all classes that
> are part of the public API [2].
>
> Footnotes:
> [1] http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++
> [2] http://en.wikipedia.org/wiki/Opaque_pointer
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.
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
