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  extension (RFC 5464  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 , 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 that warning and to schedule the meeting anyway, or to return to the editor dialog for meeting time adjustment. It is planned to provide a configuration option whether or not a user wants these warnings or not. Of course, in offline mode, there is no f/b information available, so this will work in online mode only (Kolab specific: no, just needs free/busy information) * 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 . 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, ) (Kolab specific: no) * Setting/editing Kolab folder types on Kolab IMAP folders. This will be a UI extension allowing the user to manually set Kolab folder types on IMAP folders residing on an IMAP server which offers the ANNOTATEMORE capability. There are a number of Kolab folder types , and according to the folder type set as an IMAP annotation, the frontend / backends will care for these folders or leave them alone. In order to use Evolution as a standalone Kolab client, this functionality is needed. Currently, when creating new IMAP folders in Evo via the 'kolab2' provider, these will automatically get annotated as email folders. There is currently no way to create Kolab PIM folders with evolution-kolab. Users need to resort to other clients like the Horde webfrontend for Kolab to do this task. Also, it is useful to recover from certain error situations to have this functionality. One could try and implement a generic user interface for editing folder annotations, but then the user would have to know exactly which annotations to set (instead of simply selecting one from a drop-down-list) (Kolab specific: yes, most probably) Several thoughts now cross my mind, which I would like to dump here in no particular order, hoping for enlightenment: The "Setting/editing Kolab folder types on Kolab IMAP folders" work package could profit from a generic way of communicating with the backends. Say, a user creates a new IMAP folder with the 'kolab2' provider. By default, it will be annotated as an email folder. Now, the user changes the folder type by the extension described above. Let's assume this is done in Evo by making use of the extended API of the kolab2 provider, then the backends need to be notified to look for a new folder on the server they are supposed to care for (instead of having to poll the server regularly from the backends, which is not nice). Lacking such a mechanism, the backends need to be restarted to notice the new folder or be polling. In 2.30, we need to configure all PIM folders manually, whereas Evo (or any other E-D-S client) could just ask the backends about the calendars/address books they offer and present them to the user. Has some infrastructure been implemented in recent Evo/E-D-S already? Sorry if I missed the discussion on the list (pointer welcome). That's it with the dump so far. Now I'm eagerly awaiting the input you'll have for me. Kind regards, Christian  http://tools.ietf.org/id/draft-daboo-imap-annotatemore-05.txt  http://www.faqs.org/rfcs/rfc5464.html  http://mail.gnome.org/archives/evolution-hackers/2011-September/msg00030.html  http://www.faqs.org/rfcs/rfc4314.html  http://wiki.kolab.org/index.php/IMAP_Annotations [6[ http://kolab.org/doc/kolabformat-2.0rc7-html/c159.html#AEN162 -- kernel concepts GbR Tel: +49-271-771091-14 Sieghuetter Hauptweg 48 D-57072 Siegen http://www.kernelconcepts.de/
Description: This is a digitally signed message part.
_______________________________________________ evolution-hackers mailing list email@example.com To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers