[Kolab-devel] Kolab2 architecture/format flaws

[Martin Konold]

Hi,

I additionally forwarded your questions to kolab-format at kolab.org

Yours,
--martin

Am Donnerstag, 12. Mai 2005 21:18 schrieb 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?