[Kolab-devel] Is IMAP still the right choice?
Georg C. F. Greve
greve at kolabsys.com
Wed Nov 30 11:52:45 CET 2011
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
> 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.
Georg C. F. Greve
Chief Executive Officer
Kolab Systems AG
e: greve at kolabsys.com
t: +41 78 904 43 33
pgp: 86574ACA Georg C. F. Greve
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 308 bytes
Desc: This is a digitally signed message part.
More information about the devel