[Kolab-devel] 10.000 events in a Resource Calendar

[Martin Konold]

Am Dienstag, 22. Mai 2012, 11:55:35 schrieb Jeroen van Meeuwen:

Hi Jeroen,

> > - Freebusy only changes when new IMAP objects are created in a
> > calendar
> > (remember that there is no modify)
> 
> This assumption is fairly flawed, since removing events from a calendar
> does not add new IMAP objects but MUST update free/busy.

No this is not a flaw in any way. A delete operation is handled exactly like 
and together with write operations. (E.g. EVERY modify is actually a 
delete+write operation by nature of how Kolab storage works)

> > - Kolab creates partial freebusy information whenever a new object is
> > written to a calendar folder in IMAP
> 
> Euh, as far as I know, it is the client software that triggers an
> update of the free/busy, and not the Kolab server itself, and unless the
> client is multi-threaded like Kontact it is also a blocking operation.

Sorry this is non-sense. The Kolab client _triggers_ the creation of of the 
freebusy information. Such a trigger is trivially non-blocking and the time 
required is totally independent of the folders size (perfect O(1). There is no 
need for multi-threading here. 

The main point here is that the Client trigger the update of the partial 
freebusy data but they never wait nor block. (A trigger is simply an http call 
which immediately returns and hints the server that the freebusy needs to be 
updated)

> > - When an invitation e.g. via iTip arives you simply need to check
> > for an
> > overlap with the freebusy list of the user involved (freebusy is the
> > set union of the partial freebusy lists)
> 
> See the former, ...
> 
> While Free/Busy and the way that it is going to work is in flux, and
> while Free/Busy will itself need to do somewhat the same "query" against
> raw IMAP, I'm inclined to seek ways the querying itself can be improved.

Sorry, but you really got things wrong. The basic idea behind Kolab is NOT to 
think in terms of a relational database including terms of doing queries all 
the time.

This is the essential clue behind Kolab that it is so extremly scalable.

Introducing all these "query" concepts will lead to loosing this unique 
property.

IMHO the Kolab 3.0 architectures runs in the wrong direction.

Regards,
-- martin

-- 
--  
e r f r a k o n
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker
Sitz: Adolfstraße 23, 70469 Stuttgart, Partnerschaftsregister Stuttgart PR 126
http://www.erfrakon.com/