[Kolab-devel] Kolab2 architecture/format flaws

[Zachariah Mully]

On Wed, 2005-05-11 at 16:34 -0400, Zachariah Mully wrote:
> Hello all-
> 	I posted awhile ago about speed issues while using the webclient
> calendar. Since groupware is becoming a serious albatross around my
> neck, I've done some digging and found a serious scalability problem
> with the Kolab drivers in Horde. 
> 	AFIACT, in kronolith/lib/Drivers/kolab.php, the function 'listEvents'
> is called whenever calendars are viewed. The function does not use any
> date bounds on the query to generate the events list, so it returns
> *ALL* calendar events past and present for every calendar in the view.
> Even if the view was a single day, it'll return many years worth of data
> (if available), which is then simply thrown away. 
> 	What I'm curious about is how other clients handle this same situation,
> and how calendar views are generated in a way that doesn't require each
> and every message in the store to be fetched and scanned for any
> calendar operation. I'm guessing that desktop clients (Kontact,Toltec,
> etc) maintain a local cache on disk of the folder that they can search
> through... If not, how are you scanning the xml efficiently? I would
> like to implement date limits for the listEvents function, but because
> the xml is the body of the message, there isn't a good way to search for
> events within a date range.
> 

Okay, I've been looking at this problem and I had a solution, but it
appears I've been stymied again by the Kolab2 XML format. I had planned
on using the IMAP SEARCH BODY command to limit the number of messages
returned, but I just discovered that the IMAP SEARCH command can't
search the contents of the Kolab objects:

A144 SELECT INBOX/Calendar
* FLAGS (\Answered \Flagged \Draft \Deleted \Seen)
* OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Deleted \Seen \*)]  
* 13 EXISTS
* 0 RECENT
* OK [UIDVALIDITY 1105033006]  
* OK [UIDNEXT 470]  
A144 OK [READ-WRITE] Completed
A145 SEARCH (OR (BODY <start-date>2005-03) (BODY <end-date>2005-03))
* SEARCH
A146 SEARCH BODY "Kolab Groupware Object"
* SEARCH 1 2 3 4 5 6 7 8 9 10 11 12

Because the Kolab attachment is set as "Content-Type:
application/x-vnd.kolab.event" which the IMAP has no clue about... If
you set the Kolab object as "Content-Type: text/xml" it works fine. As
it stands now the only content searchable in the Kolab objects is the
dummy text.

So a couple questions for the developers and storage spec writers: 

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? 

2) Since this format makes using IMAP as the storage provider an
exceedingly poor choice, is the storage specification for Kolab2
finished and fixed? Any chance to lobby for a change from the kolab
specific mime-type to text/xml for instance? 

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? 

4) Without format changes, I consider the possibility of a workable
*scalable* webclient, in any form, dead in Kolab2. Was a robust
webclient ever part of the plan for Kolab2?


Z