Re: [Evolution-hackers] Evolution 3.8 Planning

[Matthew Barnes <mbarnes redhat com>]

On Wed, 2012-09-05 at 09:57 +0200, Christian Hilberg wrote:
> Thanks for the heads-up. I remember you mention some sort of API
> restructuring / rework concerning E-D-S, D-Bus and EClients you had in
> mind for 3.7/3.8 cycle. Do you have anything cooking in this regard
> already? Might be worth putting on that page.

My plan is to write XML interface specifications for all our calendar
and address book D-Bus interfaces, use gdbus-codegen to generate the
GDBus classes, and throw away our old "egdbus" libraries.

I've already made some progress on this.

We're currently using gdbus-codegen to generate the GDBus classes for
the evolution-source-registry service.  It's a fantastic tool and the
XML interface specs are much easier to maintain and extend.

As I recall, the current D-Bus classes in our internal "egdbus"
libraries were generated once by some now-unsupported and non-working
precursor to gdbus-codegen, so we've been stuck hand-maintaining the
generated C code.  That makes any D-Bus interface changes we wish to
make (such as adding a "synchronize" method) a royal PITA.

While I'm at it I'll be deprecating some parts of the EClient APIs whose
function signatures imply they're non-blocking but in fact make blocking
D-Bus calls, and replacing them with proper cancellable synchronous and
asynchronous functions.  I'll try my best to NOT break the libebook and
libecal APIs.

Not yet sure of the impact to backend APIs, I'll know better shortly.

Since I'm hoping to wrap this up in time for 3.7.1 and it's really just
a cleanup operation, I'm not sure if it's worth listing on the planning
page.  If the scope of this project balloons too much I may reconsider.

Matt