[Kolab-devel] extended freebusy-lists
wrobel at gentoo.org
Fri Jul 7 23:29:36 CEST 2006
Bernhard Reiter <bernhard at intevation.de> writes:
> sorry for the late reply.
> I have been away for a few weeks (yes some vacation as well).
No problem at all.
> The intention is to modell a use case.
> People would often like to see an overview about the calendar of their group.
> Giving everybody full read access to all persons within the group is not the
> best solution as this detailed information is not necessary. Also Outlook has
> problems dealing with many calendar folders. Thus the idea was born to use
> the web for this and add the necessary information to an extended freebusy
> view. This view could also be another privacy layer.
>> X-SUMMARY does not seem to be used anywhere, but groupware clients
>> could access this information if they fetch the *.xfb file. Which
>> clients use this information?
> /fbview currently uses it.
> If you have read access to a user you are adding to the view, you will see the
> summary in the tooltip of marked busy time.
> We are currently thinking about
> a) to add the place of the appointment as well
> b) how to model access to the xfb information, currently access is too
> restricted to make it useful.
Ok, I understand. So this is something that needs to be in there.
>> There are two problems that I do see with these extended attributes:
>> 1) They are erased before ever being accessible
> I have not checked yoru code analysis,
> but I can see the summaries in the xfb lists,
> so they must not completely be gone.
Hm, might have misinterpreted something. Maybe I looked at the wrong
version of the code. I'll check this again.
>> 2) Merging free/busy attributes results in loss of X-* attributes
>> The function simplify within the vfreebusy.php script looks like it
>> throws away the extra parameters of an event if it finds a new event
>> that overlapy the first one. There seems to be no guaranteed order of
>> preference. I believe this might interfere with the intetion of
>> ignoring event updates as they are handled by the freebusy.php script.
>> So I would like to know what the intention of the X-* attributes are
>> and how handling of event updates is supposed to work.
> From the logic for the summary display, throwing away when merging seems fine,
> though I think best would be to have the overlapping peroid to preserve the
> other information like summary or place in the future.
Ok, so this should be solved in a different way. I'm going to check if
I can come up with something reasonable.
> Thanks a lot for your well written analysis!
> We are still bad reacting at your analysis, this is partly because we lack the
> developer time. Still your help is appreciated a lot, even when we react
I don't have any expectations that need to be met :) Thanks for your
Gunnar Wrobel Gentoo Developer
Mail: wrobel at gentoo.org
IRC: #gentoo-web at freenode.org
More information about the devel