Hi all. Am Dienstag 13 September 2011, um 15:56:00 schrieb Christian Hilberg: > The evolution-kolab team is currently planning to port the evolution-kolab > plugin to the recent developer version of Evo/E-D-S. I have had a discussion > [...] In order to get a clearer picture of the changes in Evo and E-D-S since version 2.30, I have been groveling through the list postings in search for major changes which will affect the porting (and later extending) of evolution-kolab. I have condensed my findings into a text file which I found might be helpful for others as well, so I'm posting it here. It is evolution-kolab centric of course, and it leaves out all changes which do not affect an E-D-S plugin, also it may not be exhaustive. But hey, you get it free of charge. ;-) Here it is, have fun: -------------------------------------------------------------------- evolution-kolab - major Evo/EDS changes since 2.30 created: 2011-09-13 Christian Hilberg changed: 2011-09-14 Christian Hilberg -------------------------------------------------------------------- Camel ------------------------------------------------------------------------------ Thread: http://mail.gnome.org/archives/evolution-hackers/2010-September/msg00037.html "Re: [Evolution-hackers] Camel Manifesto (update)" Objective: * Redefinition of CamelOperation * Rename blocking methods * Asynchronous Methods (new asynchronous API) * CamelStream API change evolution-kolab affected classes: * KolabMailImapClient * everything using CamelStreamMem ------------------------------------------------------------------------------ Thread: http://mail.gnome.org/archives/evolution-hackers/2011-April/msg00093.html "[Evolution-hackers] CamelService changes" Objectives: * new Camel XDG file system layout * CamelService, CamelSession API changes evolution-kolab affected classes: * CamelKolabSession * CamelKolabStore * KolabMailImapClient ------------------------------------------------------------------------------ Thread: http://mail.gnome.org/archives/evolution-hackers/2011-June/msg00016.html "[Evolution-hackers] Rethinking Camel settings" Objectives: * introduction of CamelSettings class * settings propagation through Camel classes * plans for "binding mail account settings to ESourceExtensions" evolution-kolab affected classes: * CamelIMAPX* * CamelKolab* ------------------------------------------------------------------------------ Evo / EDS (non-Camel) ------------------------------------------------------------------------------ Thread: http://mail.gnome.org/archives/evolution-hackers/2010-November/msg00013.html "[Evolution-hackers] Rethinking account management" Objective: * move from GConf to key files (details key file layout) * establish ESourceRegistry (monitoring of config changes) * rewrite of ESource*, API change * connect backend-discovered sources with account evolution-kolab affected classes: * ECalBackendKolab * EBookBackendKolab ------------------------------------------------------------------------------ Thread: http://mail.gnome.org/archives/evolution-hackers/2010-November/msg00054.html "[Evolution-hackers] Account management and keyrings" Objective: * integration of GNOME keyring with the new account management handling * password handling and storing in ESource / EAccount * ESource password API for frontend/backend use evolution-kolab affected classes: * ECalBackendKolab * EBookBackendKolab ------------------------------------------------------------------------------ Thread: http://mail.gnome.org/archives/evolution-hackers/2011-January/msg00004.html "[Evolution-hackers] Install E-D-S backends into separate directories?" Objective: * separate installation directories for calendar and address book backends * issues with GTypeModule and backend type registering * ESource interferences with GTypeModule (and solving strategy) evolution-kolab affected classes: * ECalBackendKolab * EBookBackendKolab ------------------------------------------------------------------------------ Thread: http://mail.gnome.org/archives/evolution-hackers/2011-March/msg00064.html "[Evolution-hackers] Front-end header files for E-D-S libraries" Objective: * create toplevel header files for each E-D-S library * deprecate inclusion of individual lower-level headers evolution-kolab affected classes: * potentially all ------------------------------------------------------------------------------ Thread: http://mail.gnome.org/archives/evolution-hackers/2011-March/msg00075.html "[Evolution-hackers] Backend requesting arbitrary user input from frontend" Objective: * how to allow backends to ask for user data * case at hand: user PIN (cannot be stored) * signaling from backend to frontend to request for data evolution-kolab affected classes: * ECalBackendKolab * EBookBackendKolab * KolabMailImapClient ------------------------------------------------------------------------------ Thread: http://mail.gnome.org/archives/evolution-hackers/2011-April/msg00065.html "[Evolution-hackers] New 'eclient' branch in eds" Objective: * EClient asynchronous API ("following glib/gio async pattern"), semantics and implementation * EClient types * unified ECalBackend authentication process with that of EBookBackend * ECredentials (authenication, passwords), interface and implementation * ESource / EClient overlap issues and API changes * error handling * free/busy APIs, ECalView * evolution-kolab affected classes: * ECalBackendKolab * EBookBackendKolab * CamelKolabSession ------------------------------------------------------------------------------ Thread: http://mail.gnome.org/archives/evolution-hackers/2011-August/msg00025.html "[Evolution-hackers] Further thoughts on ESources" Objective: * D-Bus service for (ESource) key file management and monitoring * provide a place for groupware plugins to install monitoring modules evolution-kolab affected classes: * none so far, important for extending evolution-kolab functionality ------------------------------------------------------------------------------ Thread: http://mail.gnome.org/archives/evolution-hackers/2011-September/msg00015.html "Re: [Evolution-hackers] Moving EExtension to libedataserver" Objective: * deriving EBookBackend and ECalBackend from EExtension * moving EExtension to libebackend * introduction of EBackend, EBackendFactory, EDataFactory ("factor out some of the common pieces of their libedata-book and libedata-cal counterparts and serve as abstract base classes") * API breaks for libebackend, libedata-book, libedata-cal evolution-kolab affected classes: * ECalBackendKolab(Factory) * EBookBackendKolab(Factory) ------------------------------------------------------------------------------ -- kernel concepts GbR Tel: +49-271-771091-14 Sieghuetter Hauptweg 48 D-57072 Siegen http://www.kernelconcepts.de/
Attachment:
signature.asc
Description: This is a digitally signed message part.