Re: [Evolution-hackers] Evolution 3.8 Planning

[Christian Hilberg]

Hi Matt,

Am Dienstag 04 September 2012, um 17:05:36 schrieb Matthew Barnes:
 Few quick announcements:
 
 I started a new planning page on the wiki for Evolution 3.8 and seeded
 it with a few items.  Would appreciate seeing it fleshed out a bit more.
 
 https://live.gnome.org/Evolution/Planning38

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.

 Milan and I discussed gnome-3-6 branches today.  I'm ready to branch and
 begin 3.7 development now, but for the sake of translators we'll hold
 off until September 17 when GNOME 3.5.92 enters its hard code freeze.

Sounds good to me.

 Also I'll be taking personal time off the latter half of this month, as
 will Milan I believe.  So you may be hearing crickets in #evolution for
 couple weeks.  I'll still have email and will get the 3.6.0 release out
 on time.  Returning the first week of October.

That's some valuable bits of information, thanks.

 Matthew Barnes

Kind regards,

Christian

-- 
kernel concepts GmbH   Tel: +49-271-771091-14
Sieghuetter Hauptweg 48
D-57072 Siegen
http://www.kernelconcepts.de/


signature.asc
Description: This is a digitally signed message part.
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Evolution 3.8 Planning

[Matthew Barnes]

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