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
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 [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)
* 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 [5][6], 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
[1] http://tools.ietf.org/id/draft-daboo-imap-annotatemore-05.txt
[2] http://www.faqs.org/rfcs/rfc5464.html
[3] http://mail.gnome.org/archives/evolution-hackers/2011-September/msg00030.html
[4] http://www.faqs.org/rfcs/rfc4314.html
[5] 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/
Attachment:
signature.asc
Description: This is a digitally signed message part.