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.

_______________________________________________
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Reply via email to