Proko2 is Good News Towards Kolab2

[Marc Groot Koerkamp]

Jon Bendtsen said:
> Den 14. apr 2004, kl. 13:11, skrev Bo Thorsen:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On Wednesday 14 April 2004 08:48, Ivaylo Toshev wrote:
>>> True. but againt: I mean totally different approach of storage - not
>>> in
>>> client but on server. I know that this is totally different technical
>>> conception compared with current kolab, but if this is some kind new
>>> project, i thought that considering this option will not be just waste
>>> of time.
>>
>> Well, no one will stop you from doing that of course. But the Kolab
>> concept in this part is so basic that it's next to impossible to
>> change.
>> We chose an IMAP based solution from day 1 with this project, back more
>> than two years ago.
>>
>> Now, if you don't want to replicate locally, why not just use the
>> non-storing mode of KMail IMAP? Or use POP3 to remove the mails from
>> the
>> server? By not using a database, options like these are available too.
>
> yes i know. What i was looking for was perhaps a choice of using Maildir
> based IMAP as kolab does now? or using a DB based IMAP.
>

I think the whole discussion about DB based imap is useless. What matters
is that kolab makes use of IMAP. IMAP is a rich protocol with a lot of
features like SEARCH. The only thing a client should worry about is
talking IMAP.
The client has the capability of caching imap folders / messages. If a
search request is done and the target are folders which are completely in
sync and cached localy then the search request is processed by the client.
However if folders like shared folders located on the imap server which
are not cached locally then there is no need at all to download all those
folders to the local cache. Instead only the headers of the returned uid's
from the search command should be send to the client and if the client
decides to open the message then the rest of the message can be cached.

How the  messages are stored on the server is irrevelant for the client
because the used protocol is IMAP.

If you want a DB backend for imap folders/messages on the server then you
are talking about replacing cyrus as imap server and replace it by dbmail
or whatever. It would be insane to write your own imap server.

So the question left is why do you want an imap server with a db-backend?
If it's speed then I doubt if a db based imap server is quicker then cyrus.
If you want to bypass cyrus to access messages then I want to know why
that's usefull because you should use the imap protocol for that.

The only valid reason for a database backend could be caching calendar
related data for webbased clients (without local cache) because
reconstructing a calendar view by parsing every message in a calendar
folder is an expensive operation. It can be convenient to have knowledge
about which messages to fetch for creating for example a month view with
vevents without the need for fetching all messages.


Regards,

Marc Groot Koerkamp