[Kolab-devel] Is IMAP still the right choice?
Jeroen van Meeuwen (Kolab Systems)
vanmeeuwen at kolabsys.com
Wed Nov 30 13:32:22 CET 2011
On 2011-11-30 10:52, Georg C. F. Greve wrote:
> 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.
Note that, on a Kolab 2.3 server (Cyrus IMAP 2.3), CONDSTORE is not
enabled for mail folders by default. Polling for updates on the
server-side of things becomes a lot more complex without it. I don't
think Z-Push's Kolab backend (through Horde) currently uses this
functionality even when enabled, but if it does, the following could
mean a significant performance improvement as well;
>> 2) not really full search functionnality (try to search for an event
>> example without cache who is a really a bad thing on a big calendar
>> must iterate all the mails .....)
> Again: You can search for the event's UID in IMAP, cached by server.
Note that the indexing job that is squatter is not enabled by default
on a Kolab 2.3 server. This is the indexing job that makes searches that
do not just include header searches, not have to read all files in a
A line that would enable that, to add to one's
/kolab/etc/kolab/templates/cyrus.conf.template, would be:
squatter cmd="squatter -s -i" at=0130
in the EVENTS section.
> 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
> reasons, independently of the storage used, has nothing to do with
I think there may be one exception, Exchange 2010 EWS ;-)
>> 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
>> 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
> complex as LDAP ACLs, that would just be inviting accidental leaks
> and lots of trouble.
I can give you the most complex LDAP ACL to use in a Cyrus IMAP ACE and
it'll all be dandy to the user. It's called dynamic groups.
On the subject of privacy/sensitivity, currently IMAP is the only
technology worked on that can make things *actually* private. It's
called per message annotations, of which the private side can store a
key to decrypt the contents of a message with, so that only
john.doe at example.org is eligible to read (parts of) the contents of a
Up and until now, privacy either meant messages in a folder that no-one
else had access to, or a client recognizing a 'private' flag having been
set and thus not displaying the message contents (despite the fact the
message is actually readable in full detail).
Jeroen van Meeuwen
Senior Engineer, Kolab Systems AG
e: vanmeeuwen at kolabsys.com
t: +44 144 340 9500
m: +44 74 2516 3817
pgp: 9342 BF08
More information about the devel