Having a calendar item subtyped from event also means you can't extend event to create custom calendar entries, say a bugtracker event which is a release deadline by which time your assigned bugs must be fixed.
in which Ben summarizes some of the problems with the datamodel and in which someone describes how they poached then modified the datamodel for a Java project they were working on.
I think it would be nice to have the actual calendar content be a content (repository) type so one could register a template to it and control how the calendar event is displayed by the calendar package.
The project I allude to above solved issues by removing content item and adding a mapping table to map a calendar event to one or more calendars.
The existing calendar packages, sick as it is, functions well enough for many needs and while not bug-free is fairly stable. I'm inclined to think in terms of a datamodel rewrite resulting in a "new-calendar" package , i.e. to ignore the writing of scripts to upgrade from the old to new datamodel. I fear that trying to live with that constraint might hinder the design of a new, cleaner datamodel.
What do other folks think? Are some of the folks in this thread willing to work on redesigning the datamodel? I think a lot of the existing code - especially the widget and graphics code - could be poached without much effort once we have a decent datamodel.
I have a tarball of the old Ars Digita room reservation system if you're interested in looking at it, Denis.