[Kroupware] KMail/Kroupware report from Osnabrück

[Bo Thorsen]

KMail status in kroupware.
--------------------------

During the Osnabrück meeting, the KMail merge to HEAD was
completed. This means we have added Disconnected IMAP, MDN, vacation
setup, automatic resource scheduling, an IMAP Resource backend to
KMail, and KOrganizer connectivity for groupware scheduling.

Here, I will give an overview of each of these technologies.

The Disconnected IMAP account.
------------------------------

Disconnected IMAP - from here on dIMAP - works by synchronizing the
IMAP server contents to the local disk. The KMail user will after the
sync work on the local cache, and upon the next synchronization, all
local changes will be uploaded to the server before new mails are
downloaded to the local cache. The basic idea is that after the
synchronization, the contents of the server and the local cache are
identical.

The user benefits in this is that you do not have to be online to go
through the mail boxes. It is also an easy way to make two machines
have the same mail setup - for example you workstation and a laptop.

With the current IMAP implementation in KMail no local cache is used
which means the user must be online while going through the mail
boxes. The biggest user benefit in this is that you local disk usage
is almost zero - not a small benefit if you have several gigabytes of
email.

The future work for dIMAP includes two enhancements: Selecting a
folders to be synchronized, and creating filters for what will be
synchronized.

Carsten Burghardt have actually already implemented the folder
selection. The idea here is that normally you won't synchronize all
folders - users often have old mail archives that are not often
changed.

Synchronization filters is a setup where the user can select parts of
the folders that shouldn't be downloaded to the local cache (unless
explicitly told to do so). Examples include "Don't cache mails larger
than X kb", "Don't cache attachments" and "Don't cache mails older
than two months".

Comparing the two IMAP implementations show that the current IMAP
implementation is almost the same as the behaviour you get when using
a dIMAP implementation with a sync filter set to "Don't cache
anything" and the user deleting the cache after reading a mail. The
current implementation is very handy in the situation where users have
very little disk space available. When this isn't the case, the dIMAP
implementation should prove more userfriendly.

The implementation of dIMAP is approaching a very stable situation,
but the HEAD implementation still experiences crashes. Data loss
haven't been seen in testing since november, but the local cache has
been seen to be confused. Advice to people wanting to use dIMAP is to
backup mails they really don't want to loose. The implementation is
definately stable enough for more thorough testing so we can find the
remaining bugs that are there. Speed-wise, the implementation isn't as
effective as it could be. We have concentrated completely on stability
and sacrificed all speedups we could think of to make the
implementation as stable as it can be. The effect should be that it's
much more stable, but synchronization can take quite a long
time. Later work on this should yield big speedups in the
synchronization.

dIMAP uses the normal KMail maildir for the local cache, so
technically, what we did was to make the synchronization code and not
touch the local storage. This means that the local cache is just as
stable as having normal local maildir folders. At a later point we
hope to decouple the account code completely from the folder code, so
the user can choose which type of folder he wants as the local cache.


MDN - Message Disposition Notification.
---------------------------------------

MDNs are a generalization of what is commonly called "read
receipt". The message author requests a disposition notification to be
sent and the receiver's mail program generates a reply from which the
author can learn what happened to his message. Common disposition
types include "displayed" (i.e. read), "deleted" and "dispatched"
(e.g. forwarded).

In KMail you can request notification when people read the mail you
sent, and KMail can send notification when you read mail sent to you
with notification requests.


Vacation setup.
---------------

When your mail server supports Sieve filtering, KMail can set up
vacation notifications for you.


Automatic resource scheduling.
------------------------------

In groupware mode, you can setup accounts to work as automatic
resource scheduling. With this, you set up accounts for each resource
you want to schedule. An example could be a room. You make an account
that holds the rooms calendar, and people "invite" the room to a
meeting. When KMail receives such an invitation, it automatically
accepts if the resource is free - if not, it rejects the
invitation. We don't mind people calling this a hack, but it works
surprisingly well :-)


IMAP Resource backend to KMail.
-------------------------------

The new resource framework in kdelibs and kdepim have different
backend implementations. The obvious one is to use the local disk for
the storage, which is the standard implementation. For the
addressbook, there is also an LDAP backend, and so on.

We have implemented a resource backend in KMail, so this can be used
for storage. This means KOrganizer, KAddressbook and other
applications can save their data in KMail folders. This is
specifically done with dIMAP in mind, so synchronization in addition
to emails also syncs calendar, contacts and notes.


KOrganizer connectivity for groupware scheduling.
-------------------------------------------------

To complete the groupware functionality, code have been added to KMail
to intercept incoming groupware messages.

In KMail, different things happen depending on what is in the message
currently being read. We have added the check for mimetypes holding
calendar related information. When a message with such a mimetype is
seen, the iCal file is given to the groupware code that reformats it
to a HTML message which includes the choices the user has. So when an
invitation arrives, this is transformed to a message saying you have
been invited to a meeting in XX from YY to ZZ. Below that there are
four links with different options, the most important being accept and
decline. When the user clicks one of these links, KMail will call
KOrganizer code with the message and the user choice. After that it is
up to KOrganizer to put the information into the right resource (which
could be the IMAP resource as described above).

In addition to this, KMail also offers to format and send the messages
from KOrganizer, so correct replies and invitations are sent.

The general split here is that KOrganizer handles all iCal related,
and KMail handles how the iCal is put into mails or read from mails.

In kroupware_branch all this is working, but in cvs HEAD there are
still some issues to be sorted out before this is working. The
difference is that in kroupware_branch, all communications is done
with Qt signals and slots, where in HEAD it's done with DCOP. This is
currently being retrofitted to work in the Kontact framework and is
looking very promising.

Bo.

-- 

     Bo Thorsen                 |   Praestevejen 4
     Senior Software Engineer   |   5290 Marslev
     Klarälvdalens Datakonsult  |   Denmark