show-time-as and out-of-office in v3

Christian Mollekopf mollekopf at
Thu Jun 21 21:12:05 CEST 2012


What I get by now, is that the out-of-office thingy is an actually useful and 
requested feature, with the usecase of being able to check in a shared 
calendar if a coworker is in his office or not.

I already lined out how I would like to see that implemented, and similarily I 
would put that to the location in the Kontact UI.

So as a first step:
* Add it to kolabxml event
* Add support for it in KCalCore
* Add it to the Kontact UI

So that would already make this feature useful when looking at a shared 
calendar of a coworker, it has nothing to do with F/B so far though.

For F/B I don't see this feature to be useful at the moment. For all I know, 
the only place where you get in touch with F/B data is the event scheduling 
part of the Kontact Event Editor, and also there you only actually get to see 
it, if a conflict has been detected. So in the current state, there is IMO not 
much point in adding it to F/B which is in Kontact a pure scheduling assistant 
for detecting&resolving scheduling conflicts.

Now we want to use f/b additionally as a strapped down/read-only version of a 
calendar, which is IMO a rather different usecase.

>From a Kontact POV that means we need an akonadi resource (either kolab or 
standalone) which converts f/b into calendars, at which point the X-
OUTOFOFFICE, in the F/B object, as well as all of XFB actually becomes useful 
(as they become visible to the user).

This may all have been clear for you all along, it wasn't for me, which is why 
I wrote it down.

Regarding show-time-as and the MS equivalent (
us/library/ee219533(v=exchg.80)), I'm not aware of any usecase for it, and 
it's IMO entierly redundant:

* FREE: For scheduling purpose we have already TRANSP
* TENTATIVE: TRANSP for scheduling, we can tentatively attend to your own 
event, for the event there is STATUS with the values ("TENTATIVE", 
* BUSY: For scheduling purpose we have already TRANSP
* OutOfOffice: Is really about where I am and has nothing to do with scheduling 
or alike.

I'd be especially interested if the Roundcube developers would agree to that, 
and consequently remove it from the Roundcube UI.

Otherwise, unless somebody speaks up, I pretty much know what to do:

First steps:
* Add Out-Of-Office to kolabxml event
* Add support for it in KCalCore
* Add Out-Of-Office to the Kontact UI
* SFB for scheduling

Next steps:
* XFB (including Out-Of-Office)
* Freebusy calendars in Kontact

Where I see especially the "Next step" as something for after the first release 
of kolab 3.0 as it requires some work on Kontact, but also the UI for Out-Of-
Office + KCalCore modifications might take some time.


On Wednesday 20 June 2012 12.44:43 Christian Mollekopf wrote:
> On Wednesday 20 June 2012 11.04:43 Jeroen van Meeuwen wrote:
> > On 2012-06-20 10:45, Christian Mollekopf wrote:
> > > Hey,
> > > 
> > > I looks like we finally do need the out-of-office feature.
> > > 
> > > In kolabv2 we had show-time-as with the values free, tentative, busy,
> > > or
> > > outofoffice. Which was a mix of the TRANSPARENCY setting with some
> > > others.
> > > 
> > > In the v3 I propose the following:
> > > * TRANSPARENCY to control if an event shows up in f/b (already done)
> > > * STATUS for tentative etc. (already done)
> > > * introduce boolead x-out-of-office to LOCATION, to annotate that
> > > we're out of office.
> > 
> > Why not model this exactly the way it already has for Microsoft and
> > 
> > Apple products:
> >
> Thanks for the hint.
> The point I was trying to make is that everything except out-of-office is
> already modeled in xCal, and out-of-office is not really a scheduling thing,
> but just an information for the user that he shouldn't walk over to the
> office of the contact at that time.
> If we just add this property, as puerly informal property, which is not
> taken into account for scheduling, not much harm will be done I suppose. I
> would find the FREE/TENTATIVE/BUSY values rather pointless though.
> According to
> the semantics between TRANSP and BUSYSTATUS overlap, as the information is
> also taken into account for scheduling, which I definitely don't like.
> So I still think we should do it as I proposed. We could instead add X-
> MICROSOFT-CDO-BUSYSTATUS as informal property if you like, I could live with
> that.
> > > For the out-of-office to become actually useful, as it is a
> > > kolab-specific
> > > feature,
> > 
> > It doesn't seem to be a feature exclusive to Kolab at all.
> Indeed, not part of xCal though.
> Cheers,
> Christian
> > Kind regards,
> > 
> > Jeroen van Meeuwen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <>

More information about the format mailing list