[Kolab-devel] Free busy information

[Bernhard Reiter]

On Tuesday 31 August 2004 10:58, Stephan Buys wrote:

> My honest opinion about this is that the only real practical way to do this
> is to let the server handle all the FB lists for Calendars hosted on it...

That is not the real question
as the partial free busy list would be collected on a server
and it is possible for many partial free busy lists to generated them
on the server, too.

> This would mean some sort of daemon that generated FB lists upon request.
> or maybe a daemon that updates FB files whenever a change in a Calendar
> is detected (can be accomplished with the IMAP IDLE extension).

The problem is, that this does not solve some situations:
	 - The user has a local calender
       (or a calendar on on a completley different server)
        - we cannot find out which calendars the user has read access to
	should be in his freebusy list.

> We can also add a "Private/FB-Only/Detail" annotation to all Calendar
> folders. The client would be able to specify the "policy" for the Calendar
> (FB-Only being the default), the daemon would then honor the policy
> according and accordingly show:
> 	1) Nothing - the Calendar is private
> 	2) Only "Start-End" times - FB Only
> 	3) Details of an event - Detail/Extended FB

This does not work, because this is only one flag for many users
and the folder will only be relevant to some of them.

> Whenever you start to deal with shared resources/calendars the whole
> client-based model starts to break down. I dont think we would ever get
> a client based model to work 100%...

The client is the only one in this game that has the full control
and information about what folders should be considered for a users
freebusy list.

Creating of partial freebusy lists can be done on the servers 
where they are saved, 
but a client can have many sources and servers of calendar information.
To allow this is an advantage of the Kolab (2) design.

The problem is to save the vector of this information somewhere
and then how to do the workflow of other people being able to update
some folders.

> The way that MS-Exchange, Lotus Notes and Samsung Contact does it is on the
> fly from the server...

The Kolab design explicitely does behond the non-scalable database approach
of those servers. The idea of partial free busy list continues to make this possible
for even more sources in a consistant way preserving the simple design
that the clients keep control and do most of the work.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2145 bytes
Desc: signature
URL: <http://lists.kolab.org/pipermail/devel/attachments/20040901/5d9b5c14/attachment.p7s>