Re: [Evolution-hackers] [evolution-kolab] On porting and extending the plugin
Hi all, thanks to Matt, here are another two which I initially missed (since I was much clear that Camel would move to GObject/GError/GIO...): -- Thread: http://mail.gnome.org/archives/evolution-hackers/2009-November/msg00019.html "[Evolution-hackers] Camel Manifesto" http://mail.gnome.org/archives/evolution-hackers/2010-May/msg0.html "Re: [Evolution-hackers] Camel Manifesto (update)" Objective: * Camel moving from CamelObject to GObject * the former Camel type system is removed * introducing Camel async API * ... evolution-kolab affected classes: * CamelIMAPX* * CamelKolabIMAPX* * KolabMailImapClient * (potentially) KolabMailMimeBuilder -- Thread: http://mail.gnome.org/archives/evolution-hackers/2010-July/msg00025.html "[Evolution-hackers] Heads Up: More Camel API breakage in 2.31" Objective: * Camel moving from CamelException to GError * G_IO_ERROR for failable disk/net Camel operations evolution-kolab affected classes: * CamelIMAPX* * CamelKolabIMAPX* * KolabMailImapClient * (potentially) KolabMailMimeBuilder -- -- kernel concepts GbRTel: +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 ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [evolution-kolab] On porting and extending the plugin
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/msg4.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-
Re: [Evolution-hackers] [evolution-kolab] On porting and extending the plugin
Hi Milan, Am Mittwoch 14 September 2011, um 08:25:20 schrieb Milan Crha: > On Tue, 2011-09-13 at 15:56 +0200, Christian Hilberg wrote: > > * IMAP ACL management. A new tab (or something alike) when > > right-clicking an IMAP folder in the Evo folder tree to view and > > edit IMAP access control lists as defined in RFC 4314 [4]. The IMAP > > ACL functionality will be implemented on a new branch based on A-B > > (see "Phase I, (1)"), much the same way ANNOTATEMORE has been > > implemented, to the extend needed for Kolab. This will lead to an > > API extension (like there already is in evolution-kolab-IMAPX). > > There will be the need to extend Evolution as well, as to make it > > use this API extension. It is currently not yet planned exactly how > > this can be done without littering Evolution with "the tacking on of > > arbitrary features" (MBarnes, [3]) > > (Kolab specific: no) > > Hi, > see how evolution-exchange provides the same functionality of Folder > Permissions, it just adds a popup menu item and servers all what is > needed without any special modification on evolution side. The same > should apply for the folder type annotation editing - no change on > evolution should be needed. I'll check that. The less change needed on Evo side the better. I'm not sure yet exactly how we will be able to solve it. I do not have knowledge about how folders are handled in Exchange, but for Kolab, it is IMAP - so we need the capability for IMAP ACL, which, unless I'm mistaken, IMAPX does not yet provide. This part will be done (for now) in our IMAPX derivative, and Evo will need to make use of this functionality one way or another. ACL management is not limited to the evolution-kolab backends and is needed for the Kolab email folders (which are plain IMAP folders) as well. Maybe we can do this in an EExtension, I'll check with evolution-exchange. If the UI extension evolution-exchange provides is fine for the Evo community (which I think it is), then we could try to mimick the layout in order to try for a consistent user experience. To that respect, maybe it will be possible to iron out some common approach for the groupware plugins that way, which I think is what Matt has in mind. > With respect of creating a new folder on the kolab server other than > mail: when you do File->New->Calendar and select the Kolab group, is it > able to create a new folder and annotate it accordingly to the source > group? Evolution-mapi provides a short folder list with folders of the > certain type from which user can choose and under this is created the > new calendar (or address book). Again, no change on evo side is needed > for this. As far as creating new PIM folders goes, this is correct. This can be done entirely in the backends, provided we can re-use existing account information (which in current Evo/E-D-S should be possible). Things are different when you need to change or set the type of an existing folder manually. This is for error recovery mainly, but has been described by our sponsor as a real life scenario which from time to time happens to occur (due to server failure or client error). To do this, it will be made possible to display the PIM folders in the email folder tree (though these folder's contents will not be accessible), so you can right-click the folder and edit the annotation it carries by selecting a type from a drop down list. This is the typical way Kolab clients will provide this functionality for the user. There are a number of issues related to this, e.g. the kolab backends need to be notified of the change do they can sort of "drop" a folder they are no longer supposed to care for ... whether or not we can sanely implement this remains to be seen. The goal behind this is to enable Evolution to act as a complete Kolab client, removing the need to resort to different clients to get all tasks done. Kind regards and thanks for the hints, Christian -- kernel concepts GbRTel: +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 ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [evolution-kolab] On porting and extending the plugin
On Tue, 2011-09-13 at 15:56 +0200, Christian Hilberg wrote: > * IMAP ACL management. A new tab (or something alike) when > right-clicking an IMAP folder in the Evo folder tree to view and > edit IMAP access control lists as defined in RFC 4314 [4]. The IMAP > ACL functionality will be implemented on a new branch based on A-B > (see "Phase I, (1)"), much the same way ANNOTATEMORE has been > implemented, to the extend needed for Kolab. This will lead to an > API extension (like there already is in evolution-kolab-IMAPX). > There will be the need to extend Evolution as well, as to make it > use this API extension. It is currently not yet planned exactly how > this can be done without littering Evolution with "the tacking on of > arbitrary features" (MBarnes, [3]) > (Kolab specific: no) Hi, see how evolution-exchange provides the same functionality of Folder Permissions, it just adds a popup menu item and servers all what is needed without any special modification on evolution side. The same should apply for the folder type annotation editing - no change on evolution should be needed. With respect of creating a new folder on the kolab server other than mail: when you do File->New->Calendar and select the Kolab group, is it able to create a new folder and annotate it accordingly to the source group? Evolution-mapi provides a short folder list with folders of the certain type from which user can choose and under this is created the new calendar (or address book). Again, no change on evo side is needed for this. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [evolution-kolab] On porting and extending the plugin
Hi again, one more thought: It would be nice from my developer's point of view if it was possible to do the UI extensions via some extension mechanism like EExtension, which would speed up the implementation process for me. However, Matt has a point when he says (in [3]) that he does not want Evo to decline into some "tacking on of arbitrary features" kind of user experience. The question here is whether such an UI extension could still be done as an EExtension or should it rather be implemented in Evo itself. Kind regards, Christian Am Dienstag 13 September 2011, um 15:56:00 schrieb Christian Hilberg: > [...] > [3] > http://mail.gnome.org/archives/evolution-hackers/2011-September/msg00030.html -- kernel concepts GbRTel: +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 ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
