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

[Jeroen van Meeuwen (Kolab Systems)]

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;

   
http://planet.ergo-project.org/blog/jmeeuwen/2011/09/12/enabling-condstore-your-kolab-23-mailboxes

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

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 
mail folder.

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 
> good
> reasons, independently of the storage used, has nothing to do with 
> IMAP.
>

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

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

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

Kind regards,

Jeroen van Meeuwen

-- 
Senior Engineer, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
t: +44 144 340 9500
m: +44 74 2516 3817
w: http://www.kolabsys.com

pgp: 9342 BF08