<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Mathieu Parent a écrit :
<blockquote
cite="mid:CAFX5sbz0=eOWsMcEh_G3=o9Bk_EhPAazm9f1boBUsNLPHEHWAQ@mail.gmail.com"
type="cite">
<pre wrap="">Hello everybody,
2011/11/30 ABBAS Alain <a class="moz-txt-link-rfc2396E" href="mailto:alain.abbas@libertech.fr"><alain.abbas@libertech.fr></a>:
</pre>
<blockquote type="cite">
<pre wrap="">Hello
My Kolab experience is now of 3 years and i wrote some extension (Z-push backend) and have some big
customers who use Kolab
For me Imap is not a good storage and have some lacks that is painfull
</pre>
</blockquote>
<pre wrap=""><!---->
Some years ago, when I reviewed different FLOSS email-oriented
groupware servers, I choosed to invest some of my time in the Kolab
project _because_ it was IMAP-centered.
Having only one protocol between client and server leverage the
complexity of the infrastructure. Most of alternatives to Kolab use a
database to store all non-mail objects.
On the bellow remarks:
</pre>
<blockquote type="cite">
<pre wrap="">1) the speed and performance
we must for each client to cache everything to have a "good" performances
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
My comment was not for the mail part. Imap is well for that, but for
groupware object<br>
One of the ugly thing is with some standard client (like Iphone ) you
see groupware folders and all the messages (as mail ) inside <br>
<blockquote
cite="mid:CAFX5sbz0=eOWsMcEh_G3=o9Bk_EhPAazm9f1boBUsNLPHEHWAQ@mail.gmail.com"
type="cite">
<pre wrap="">This is the case for other methods as well. We can only leverage this
by using more indexes (see remark 2.), especially for non-mail objects
(calendar, contacts, ...).
</pre>
<blockquote type="cite">
<pre wrap="">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 .....)
</pre>
</blockquote>
<pre wrap=""><!---->
SEARCH command is implemented in cyrus-imap (rfc3501 IMAPv4.1) as well
as rfc4731 and rfc5032. IMO, this is enough for mail search
(attachment search is not implemented, but I couldn't find an RFC for
this).
For other objects search, we usually want more search functionnality:
-a: search by date for events: this is not easy because of periodic events
</pre>
</blockquote>
<blockquote
cite="mid:CAFX5sbz0=eOWsMcEh_G3=o9Bk_EhPAazm9f1boBUsNLPHEHWAQ@mail.gmail.com"
type="cite">
<pre wrap="">-b: search by fields in contacts or events
</pre>
</blockquote>
true that is really missing <br>
<blockquote
cite="mid:CAFX5sbz0=eOWsMcEh_G3=o9Bk_EhPAazm9f1boBUsNLPHEHWAQ@mail.gmail.com"
type="cite">
<pre wrap="">
"1" cannot be done without cache.
For "2", we need an IMAP extension to support XML search or to add
some of those fields to headers which are "searchable" (this is a
change in Kolab format).
Things are moving in the right direction, see for example:
- <a class="moz-txt-link-freetext" href="http://datatracker.ietf.org/wg/imapext/charter/">http://datatracker.ietf.org/wg/imapext/charter/</a>
- <a class="moz-txt-link-freetext" href="http://datatracker.ietf.org/wg/lemonade/charter/">http://datatracker.ietf.org/wg/lemonade/charter/</a>
- <a class="moz-txt-link-freetext" href="http://tools.ietf.org/html/rfc4466">http://tools.ietf.org/html/rfc4466</a>
</pre>
<blockquote type="cite">
<pre wrap="">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....)
</pre>
</blockquote>
<pre wrap=""><!---->
Do you have any idea how to not duplicate info in cache for periodic events?
</pre>
</blockquote>
<blockquote
cite="mid:CAFX5sbz0=eOWsMcEh_G3=o9Bk_EhPAazm9f1boBUsNLPHEHWAQ@mail.gmail.com"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
<pre wrap=""><!---->
Granularity to the folder is probably enough. Isn't it?
</pre>
</blockquote>
<br>
<blockquote
cite="mid:CAFX5sbz0=eOWsMcEh_G3=o9Bk_EhPAazm9f1boBUsNLPHEHWAQ@mail.gmail.com"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">5) buggy duplication info the software must control for example the UID duplication that is a pain and a lost of time
</pre>
</blockquote>
<pre wrap=""><!---->
Isn't uid controlled by Cyrus? Do you have an example of uid
duplication? AFAIK, uidvalidy doesn't change much in Cyrus.
</pre>
</blockquote>
I meant Kolab UID not Message UID<br>
you can have 2 or 3 or more messages with an object with the same Kolab
UID because for example a modification occured (add, deletion) but for
some reason deletion failed <br>
in a database for example or LDAP you have the UNIQUE KEY to prevent
this kind of thing. Thomas (i think , dont remember the name) posted
about that <br>
<blockquote
cite="mid:CAFX5sbz0=eOWsMcEh_G3=o9Bk_EhPAazm9f1boBUsNLPHEHWAQ@mail.gmail.com"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">This is for me the 4 main reasons to think to another storage for Kolab
</pre>
</blockquote>
<pre wrap=""><!---->
Regards
</pre>
</blockquote>
<br>
</body>
</html>