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/
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ evolution-hackers mailing list [email protected] To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
