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
[Evolution-hackers] [evolution-kolab] On porting and extending the plugin
Hi everyone. 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 on IRC with Matt, David and Milan about some aspects of the current developments in Evo and E-D-S, and how they may impact the porting and extending of evolution-kolab. Your input on my thoughts is much welcome. Our resources are pretty much limited - again - and I will need to keep a keen eye on the time I can spend on the different work packages. This will result in suboptimal design decisions here and there, much as with the initial project. That's most of a pity, but there is nothing I can change about it presently. We will, however, try to align our design decisions as much closely as possible with upcoming upstream changes. So far, I have identified two main phases of this undertaking: Phase I: Porting evolution-kolab from Evo/E-D-S version 2.30 to the current git master. No functional extending will take place here, the effort will be to just get things working the way they do under 2.30. For the whole porting process, I will not be able to spend more than the one mythical man month. Phase II: Extending the evolution-kolab functionality in conjuction with some Evolution UI extensions and use of the currently-developed new infrastructure components in Evo and E-D-S. This part has not yet been fully thought through, but everything I see so far here depends on the first phase having been completed successfully. The following is planned for the two phases: Phase I: Porting * Create a new 'evolution-kolab' git repo on git.gnome.org, alongside the other E-D-S groupware plugins (preparations for doing so are completed) * Transfer the contents of the current SourceForge evolution-kolab repo to git.gnome.org. The SourceForge repo will be kept for bugfixing the 2.30 version, but no further development there * Start off with the porting work on the git.gnome.org repo The porting itself will be done in the following steps: (1) Adapt the Camel IMAPX provider used for evolution-kolab to the upstream version. This basically means to * Create a clean branch (say, A) into which to commit upstream IMAPX * Branch off of A (creates branch A-B), and re-implement the draft IMAP ANNOTATEMORE [1] extension (RFC 5464 [2] is what the ANNOTATEMORE draft finally evolved into, but current Kolab 2 servers use version 05 of ANNOTATEMORE) as it was done for 2.30, but using clean branches. In case of upstream IMAPX fixes, these will be applied onto A and A-B rebased, so a clean patchset can be generated with these two branches * The really clean way, i.e. doing this upstream directly, cannot be pursued right now since Camel does not export IMAPX, and evolution-kolab needs to subclass the extended version of IMAPX for the Kolab-specific parts (changing Camel to export IMAPX will be taking too much time for this project to do it ourselves - same problem we had when initially implementing evolution-kolab) (2) Subclass the locally extended IMAPX provider to add the Kolab-specific bits to it * For the curious, see the src/camel/ directory of evolution-kolab and how it relates to src/camel/providers/imapx/) * Once done, the new 'kolab2' provider can be tested with Evolution frontend (3) Adapt the backends glue code to the new E-D-S infrastructure * This will most likely include switching to a fully asynchronous implementation for evolution-kolab (which is presently a synchronous backend but uses notifications here and there anyhow) (4) Port the existing EPlugin account setup and Kolab folder configuration dialogs * As Matt suggested in [3], we will be sticking with EPlugin for the account stuff for time being * Since evolution-kolab needs Camel configuration details in the backends, we're not sure how this will fit with the new ECredentials framework or the account management infrastructure Matt is working on Phase II: Extending functionality This phase has not yet been planned fully. Phase I needs to be concluded successfully before this phase can start. The following is planned, more may follow: * Tooltip extension of the free/busy dialog. Kolab2 supports extended free/busy lists, which evolution-kolab can already retrieve. If extended f/b information is available (typically, this is the event subject) for a certain user, moving the mouse pointer over a time slot marked as busy, the extended information will be displayed as a tooltip window (Kolab specific: no, but needs extended free/busy information (XFB)) * Group meeting attendee busy warning. When scheduling a group meeting and free-busy information is available, the user can opt to receive a warning if any attendee of the meeting is busy during the time the new meeting is going to be scheduled for (this is, when trying to submit the new meeting entry). It will be possible to ignore t
