[Kolab-devel] Kolab2 architecture/format flaws

[Bernhard Reiter]

HI Zach,

first thanks for your feedback, I appreciate it.

> Am Donnerstag, 12. Mai 2005 21:18 schrieb Zachariah Mully:
> > On Wed, 2005-05-11 at 16:34 -0400, Zachariah Mully wrote:
> > > I'm guessing that desktop clients
> > > (Kontact,Toltec, etc) maintain a local cache on disk of the folder that
> > > they can search through... 

Yes, they do.

> > 1) Why oh why did you pick a mime-type that the IMAP server has no
> > ability to search through, and *still* decided to use an IMAP server for
> > the storage provider?

Because this is the correct mime-type according how we figured mime-types
can be used.  There probably should be a way to teach the imap server about
which mime-types are searchable.

In addition, searching of the body or the headers on the imap server should never
be necessary, due to a good caching on the client. Otherwise we are loosing
the scalability of the design step by step.
So any client that does not cache the connection of imap id and data it needs
from them, is a suboptimal implementation.

> > 2) Since this format makes using IMAP as the storage provider an
> > exceedingly poor choice, is the storage specification for Kolab2
> > finished and fixed? 

We are in release candidate state for the version 2 storage format,
this basically means deep freeze except major problem fixing.
Of course input for improvements for next versions and feedback
about major problems for this one are highy appreciated.

> > Any chance to lobby for a change from the kolab
> > specific mime-type to text/xml for instance?

As written above, we cannot just use any mime type.

> > 3) I noticed that the Toltec connector base64 encodes the Kolab objects
> > making any type of searching via the IMAP server impossible, is there a
> > specific reason for this?

That is a question of implementation you
have to ask Joon about., the spec specifically does not limit the encodings.
And as explained above, the design does not want to rely on 
deep server searches.

> > 4) Without format changes, I consider the possibility of a workable
> > *scalable* webclient, in any form, dead in Kolab2. 

Why?  There are several ways to implement a scalable web clients
as was discussed in depth a while ago on the lists.

> > Was a robust webclient ever part of the plan for Kolab2?

No, as Proko2 did not require and and nobody put of the effort
or the money to have one. This makes some sense as web clients
are only rarely needed with good native clients as in any reasonable secure
environment you need to touch the client installation anyway and then you
could as well install a native client which better usability.

Best,
Bernhard

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2145 bytes
Desc: signature
URL: <http://lists.kolab.org/pipermail/format/attachments/20050513/c43a6a1e/attachment.p7s>