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 _______________________________________________ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
