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

[Georg C. F. Greve]

On Wednesday 30 November 2011 10.18:35 ABBAS Alain wrote:
> 1) the speed and performance

This is primarily an issue of using IMAP efficiently, though.

A practical example: The Z-Push backend currently iterates over every 
annotation in every folder for both private and shared name spaces one command 
at a time, so 2 * n * x commands & responses. 

The same can be done in a single command & response.


> 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 .....) 

Again: You can search for the event's UID in IMAP, cached by server.

That's not to say there are cases where you want caching for different access 
modes, but that is always the case no matter which storage backend is chosen.


> 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....)

Virtually every server I know of pre-generates free/busy, and for good 
reasons, independently of the storage used, has nothing to do with IMAP.


> 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

The more complex ACLs, the more easy to screw it up.

I am not sure I want users to be able to touch anything even remotely as 
complex as LDAP ACLs, that would just be inviting accidental leaks and lots of 
trouble.


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

Not sure what that is supposed to refer to, but IMAP search makes it trivial 
to detect whether two objects have the same UID.

Best regards,
Georg


-- 
Georg C. F. Greve
Chief Executive Officer

Kolab Systems AG
Zürich, Switzerland

e: greve at kolabsys.com
t: +41 78 904 43 33
w: http://kolabsys.com

pgp: 86574ACA Georg C. F. Greve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 308 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/devel/attachments/20111130/1d576d92/attachment.sig>