[Kolab-devel] Kolab2 architecture/format flaws

[Christoff van Zyl]

Hi all

I am busy testing the Kolab setup, I have a working OX, OpenGroupware & 
PHPgroupware running. So far Kolab is pretty good, but I need to run 9 
domains on that the box. I see that Kolab don't do multiple domains, but 
you can set it up. I would really appriciate it if anybody can forward 
some ideas or docs on how to implement multiple domains on Kolab.

Thanks
Christoff


Bernhard Reiter wrote:
> 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
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Kolab-format mailing list
> Kolab-format at kolab.org
> https://kolab.org/mailman/listinfo/kolab-format

-- 
Christoff van Zyl
SNR Technical Support
Information Services Function
Berco Express (Pty) Ltd
1 Quark Crescent, Linbro Park, Sandton
Tel: +27 (0) 11 457 3284
Fax: +27 (0) 11 457 3161
E-mail: christoffv at bercoexpress.co.za