Subject: RE: Rollup of calendar content

From: "lisal" <[email-masked]>
Date: Thu, 20 May 1999 07:31:36 -0700

Isn't rollup of calendar content an implementation issue anyway?  When I
ask for "freebusy time" for a given CAPURL, isn't it up to the
implementation to decide where best to pull that information from?

While we're on the topic of hierarchy and rollup/inheritance, what's the
current status on ACL inheritance?  Scenario: If I manage a bunch of
calendars, e.g. all the calendars for all the meeting rooms in this
building, I don't want to have to set ACLs on each of them individually.

Lisa

> -----Original Message-----
> From: Frank Dawson/CAM/Lotus [mailto:[email-masked]]
> Sent: Wednesday, May 19, 1999 7:24 AM
> To: [email-masked]
> Subject: Rollup of calendar content
> 
> 
> 
> The concept of calendar content rollup is very complicated. 
> Given the time
> frame for completing this phase of our CAP work, I would like 
> to propose
> that:
> 
> Version 1 of CAP has no support for calendar content roll-up.
> 
> That is, hierarchical calendars is a term used to describe the parent,
> sibling and child relationship between different calendars on 
> a CS. It has
> an additional implication on the calendars that are searched 
> to find the
> computed value set for the VCAR for a given authenticated 
> user (i.e., go to
> the calendar in question, search its VCAR, then traverse up 
> the tree to the
> root to accumulate the computed value set for the calendar 
> access rights
> for a given authenticated user). However, hierarchical 
> calendars should not
> have an "content inheritance" implications or content rollup 
> implications
> for CAP version 1.
> 
> -- Frank
>

---

From: Alexander Taler <[email-masked]>
Date: Thu, 20 May 1999 19:09:27 -0400

Why don't we use Paul Hill's suggestion:

Paul Hill wrote in message <[email-masked]>
> 
> I'm starting to wonder if "sub calendar" is the right notion we should be
> selling.  Perhaps a flat namespace with both "default" and "nondefault"
> calendars.    A default calendar is associated with a particular "entity:
> person or thing".  It contains events as well as instructions for how to
> attach nondefault calendars.  The choices are "informational:
> [all,vevents,vtodo,vjournal]", "blocking: [all,vevents,vtodo,vjournal]".  A
> nondefault calendar is not associated with an entity.
> 
> So,cap://cal.ms.com/dmadeo would contain the following
> Info:vjournal   cap://cal.ms.com/ 848c8f7  (Firm Holidays)
> Block:all          cap://cal.ms.com/8484783  (NY Holidays)
> Block:all          cap://cal.ms.com/8334743  (Personal Items)
> Block:all          cap://cal.ms.com/3848483  (Work Items)
> Info:all             cap://cal.ms.com/3389393  (My organizational group)
> Info:all             cap://cal.ms.com/9433433  (Brown Bag lunch schedule)
> 

We can get rid of the words hierarchical, parent, and child, 
and instead define as many other properties as we see fit.
Currently we could replace PARENT with a new property 
"ACCESS" which indicates that access rights are inherited
from that calendar.

If we are really attached to hierarchical calendars, we 
could keep the PARENT property, but we'd have to define
exactly what it means.  Not rollup, not access inheritance,
maybe something to do with searching?

In the future we can add BLOCK and ROLLUP.

Alex