[Kolab-devel] Is IMAP still the right choice?

[Mathieu Parent]

Hello everybody,

2011/11/30 ABBAS Alain <alain.abbas at libertech.fr>:
> Hello
>
> My Kolab experience is now of 3 years and i wrote some extension (Z-push backend) and have some big
> customers who use Kolab
> For me Imap is not a good storage and have some lacks that is painfull

Some years ago, when I reviewed different FLOSS email-oriented
groupware servers, I choosed to invest some of my time in the Kolab
project _because_ it was IMAP-centered.

Having only one protocol between client and server leverage the
complexity of the infrastructure. Most of alternatives to Kolab use a
database to store all non-mail objects.

On the bellow remarks:

> 1) the speed and performance
> we must for each client to cache everything to have a "good" performances

This is the case for other methods as well. We can only leverage this
by using more indexes (see remark 2.), especially for non-mail objects
(calendar, contacts, ...).

> 2) not really full search functionnality (try to search for an event for example without cache who is a really
> a bad thing on a big calendar (you must iterate all the mails .....)

SEARCH command is implemented in cyrus-imap (rfc3501 IMAPv4.1) as well
as rfc4731 and rfc5032. IMO, this is enough for mail search
(attachment search is not implemented, but I couldn't find an RFC for
this).

For other objects search, we usually want more search functionnality:
-a: search by date for events: this is not easy because of periodic events
-b: search by fields in contacts or events

"1" cannot be done without cache.
For "2", we need an IMAP extension to support XML search or to add
some of those fields to headers which are "searchable" (this is a
change in Kolab format).

Things are moving in the right direction, see for example:
- http://datatracker.ietf.org/wg/imapext/charter/
- http://datatracker.ietf.org/wg/lemonade/charter/
- http://tools.ietf.org/html/rfc4466

> 3) duplicate info for some groupware object ( not easy without a lot of code to have for example things like free busy
> or the status....)

Do you have any idea how to not duplicate info in cache for periodic events?

> 4) lack on the permissions Impossible to have a granularity like a bdd or LDAP (example PRivate sensitivity who is
> just a software bit in the format we have with imap just

Granularity to the folder is probably enough. Isn't it?

> 5) buggy duplication info the software must control for example the UID duplication that is a pain and a lost of time

Isn't uid controlled by Cyrus? Do you have an example of uid
duplication? AFAIK, uidvalidy doesn't change much in Cyrus.

>
> This is for me the 4 main reasons to think to another storage for Kolab

Regards

-- 
Mathieu Parent