[Kolab-devel] Free busy information

[Stephan Buys]

Hi,

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

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

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 way that MS-Exchange, Lotus Notes and Samsung Contact does it is on the
fly from the server...

As far as security is concerned - we already have a daemon that has manager
access to all the folders, so what is the issue?

Regards,
Stephan

On Monday 30 August 2004 10:39, Bo Thorsen wrote:
> Hi all,
> 
> There has been some discussion about constructing FB lists lately, and we 
> have identified a problem with them.
> 
> In Kolab 1, it was fairly simple - when the user changed the calendar, he 
> uploaded the FB list to the server. Unfortunately in Kolab 2, this won't 
> be enough.
> 
> Consider this:
> 
> Person1 runs Kontact and person2 runs Outlook. They both use Horde 
> occasionally for web access.
> 
> Person1 has one IMAP folder and one local file containing calendar 
> information.
> 
> Person2 just has an IMAP folder.
> 
> In addition to this, both are part of a working group that has it's own 
> calendar IMAP folder, and they both have read-write access to this.
> 
> Whenever Person1 changes his calendar, he has full knowledge about all 
> folders, and can upload the FB list. However, if it's the group folder he 
> changes, he is actually modifying Person2's calendar also.
> 
> Also, when Person2 changes the group folder, he changes Person1's 
> calendar.
> 
> The problem does not exist, if it's not required that freebusy lists show 
> some reasonable data. Basically this is a tradeoff between easy to 
> implement (one person still only uploads his own fb lists) and accurate 
> (with person2 on holiday, the calendar could be wrong for a long time).
> 
> For lots of servers, there is no option to do the accurate but tricky way. 
> But for the Kolab 2 project we need to at least have the option to have 
> accurate fb lists.
> 
> There is actually a third option: If it's required to keep all calendar 
> stuff in IMAP folders, we would have a possibility to make an FB list 
> creation daemon on the server that would construct the FB lists from the 
> IMAP folder info. We have PHP code that can do this (needed for 
> car/room/... resources anyway), but it's not a good solution. At least 
> for Kontact, it's possible to connect to a lot of different servers, you 
> can have calendar info in several local files, and more. And having a 
> daemon with rights to read all calendar folders sounds like a big 
> security issue.
> 
> Bernhard Reiter (I think) came with the idea of partial free busy lists 
> (PFB). The idea is that the user has one pfb for each calendar info 
> place. So in the above scenario, Person1 has three pfbs: the personal 
> IMAP folder, the local file, and the group pfb. The requirement then is 
> that if you change something in the calendar, the pfb of it needs to be 
> uploaded.
> 
> When the user requests an FB list, the server will run a script that 
> collects the pfbs and returns a full FB list (and caches it). This script 
> is easy enough to write.
> 
> The concept sounds easy, but it's technically not simple to do. And it 
> needs support from at least all Kolab clients.
> 
> Now, to just complicate matters even more, it's quite possible that people 
> will start monitoring shared calendars - for example the secretary will 
> have a lot of folders visible, so he can know when the different groups 
> are meeting and so. But he should not get these folders contents added to 
> his FB lists. For this to work, we need a way for the user to make a 
> folder (or local file or ...) with a flag that this shouldn't be used for 
> FB lists.
> 
> So, what do you think. Do you agree that pbfs is the only solution that 
> solves all the involved problems? Is it over engineered? Do you have a 
> better idea? Stuff like this is what we need to get solved the right way, 
> for Kolab (with Kontact/Toltec/Horde...) to be a real integrated 
> solution.
> 
> I would like to get some feedback on this before I start working on a way 
> to implement it, so comments are highly appreciated,
> 
> Bo.
> 

-- 
Stephan  Buys
Code Fusion cc.
Tel: +27 11 391 1412
Mobile: +27 83 294 1876
Email: s.buys at codefusion.co.za

E-mail Solutions, Kolab Specialists.
http://www.codefusion.co.za