[Kolab-devel] Kolab2 architecture/format flaws

[Zachariah Mully]

On Fri, 2005-05-13 at 15:22 +0200, Bernhard Reiter wrote:
> HI Zach,
> 
> first thanks for your feedback, I appreciate it.

Thanks for the response, I apologize for being late to the game with my
comments...

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

Unless, of course, you need to implement a thin client. Then this design
decision has the exact opposite affect, it severely cripples an
implementations where heavy use of disk based caching is not available.
And to argue your point, you lose no functionality or scalability by
exposing the Kolab object contents to the IMAP server. Fat clients can
continue to maintain disk caches, and thin clients can exploit the
native caching and searching that Cyrus offers. Even fat IMAP clients
utilize these features, are they too suboptimal implementations?

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

This I don't understand... The mime-type has zero to do with the
contents of the message, and is replicated in the header of the message.
Unless I'm totally missing something, it was chosen arbitrarily. If it
was to allow mixed use mailboxes, and allow the client to recognize
different types of Kolab objects, the header is there and far more
easily parsable than the entire mime-body. 

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

Again, I have to argue that you're restricting functionality for no good
reason, other than semantics. I realize that it's your opinion that
client should never have to rely on the server backend to filter the
returned messages, but enabling that functionality is not exclusive of
maintaining your primary design theory.

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

?? Which list? I want to go back and read the discussions. I am not sure
how you can design a scalable thin client when it has to fetch and parse
the entire calendar store for *any* operation. The only way I can
envision doing it is to replicate all that data into an sql database,
which would allow fast searches for specific date ranges. But that would
relying on a deep server search, no?

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

I understand that this is part of your contract, and I am very
appreciative of the work and code that you've contributed to the
community... but this is extremely shortsighted. You've limited yourself
to desktop only deployments, and offered nobody a means to access their
data from an web terminal somewhere on the road. Most the salespeople I
work with, make heavy use of public terminals to check mail through our
webinterface as it's far more convenient and faster to sit down, login,
check and leave, than it is to fish their laptop out, plug it in, find a
network to connect to .... 

So I suppose what I'm worried about is that this design decision
severely hinders the development of any viable webclient, or any other
thin clients (mobile devices, for instance, no eff'in way I'm syncing
the entire calendar store over a GPRS connection), and it has no bearing
on the development or design decisions of fat clients. You're still free
to use disk caches, but you open up a whole host of server-side
optimizations for thin clients.

Z