I really like where you are going with this, and it would be very helpful. Right now I am doing the same type of thing, but have to do it through plsql on a per package basis, this isn't great for upgrading in the future (since they all call calendar differently). For example. i have integrated room reservations with calendar, buy simply creating a calendar and manually in the room reservation calling on a calendar item insert of the room reservation calendar (where the calendar number is specified by a parameter)... this is tedious, and not very elegant.
What you are basically saying is that calendar would become the way to view any acs-events/activities on a system wide level, if wanted to be seen in calendar... where acs-events are created and presented through a clean tcl api... Maybe, you should consider making this "higher level" calendar service an acs-events service, where calendar simply becomes a way to present acs-events in a nice, easy to see way month/week/day view. That way, if somebody doesn't want the "calendar view" lets say for an event in the events package, they can interface with the individual event display template and use that template within the events package (i.e. displaying info in events and within calendar would be the same since the service contract is with acs-events)... This would allow for multiple display options, that can be selected on a per site basis, or on an extra and intranet differently (where extranet would be a list, and intranet would be within calendar). I'm thinking maybe the acs-event display templates would be stored as cr_templates... And they could then be easily customized on a per site basis... anyways, those are some ideas.
