[Zope] Calendar (was: Portal idea)

[Phillip J. Eby]

At 04:37 AM 9/5/99 +0900, somebody wrote:
>
>>Event ZClass (inherits from CatalogAware, ObjectManager)
>> - EventDate ZClass (may inherit from CatalogAware for doing date-range
>>manipulation)
>>
>>Event could have a function, as Itamar suggested, that zips through the
>>EventDate objects (<dtml-in "objectValues('EventDate')">) and sees if there
>>is a match.
>>
>>Or, you could grab all matching EventDate objects (through the Catalog) and
>>then use parent[1] to get the Event info.
>>
>>This is a one-to-many relationship with no redundancy, and it should perform
>>pretty well, I think.

I've given the subject of events quite a bit of thought.  In addition to
the one-up, recurring, and range problems, there is also the small matter
of timezones, and efficient searching for what items should be displayed on
what 'day', even though what constitutes a 'day' differs for different
timezones.  My thoughts go like this:

* Events, Meetings, and the like may have a 'Schedule' object associated
with them.  The Schedule contains zero or more CalendarEntry objects.

* CalendarEntry objects model a single UTC timespan - i.e. a start and stop
timestamp.  They provide a (multivalued) calendar_date attribute which can
be cataloged.  calendar_date is a list of all the dates (in UTC terms)
which the event intersects.  (Note that this requires ZCatalog to support a
'MultiValueIndex', which it doesn't yet.  I say 'yet' because it's
something I want to code up when I get around to it.  It looks like a
pretty trivial addition.)

* When displaying a calendar, search for CalendarEntries with calendar_date
values for both the desired day, and either one day forward or one day back
from the desired day, depending on your relative timezone to UTC.  Then
look at the start/stop timestamps of the entries to weed out items which
aren't really a match.

* Because CalendarEntries (and the Schedules that contain them) acquire
attributes and methods from their containing Event, Meeting, or whatever,
they do not need to contain any other data, unless there are more specific
notes.  If a particular calendar wants to work its way upward through the
acquisition tree to provide a broader view of an event, with many scheduled
items for the same day (e.g. a seminar with lots of classes), it can do so.
* To handle recurring events, give Schedules the ability to generate
recurring CalendarEntries by way of a dialog that asks for a highest and
lowest date to generate, and the parameters for recurrence.  This method
would just create the requisite CalendarEntries, and perhaps store the data
used to generate them to be used as a default for the next time the
generation needs to be run.  Ideally, it would save the next value that
should be used for a start date.

* If Schedules are ObjectManager derivatives, it should be possible to
easily view/add/edit/delete individual CalendarEntries from the Schedule.

I think that about covers it.  Notice, by the way, that it really doesn't
matter where you put a Schedule object.  It could be attached to anything
that needs a schedule, like a room, a person, a project...  If Schedules
have a property that determines whether conflicts are allowed, so much the
better.  Schedules could also provide some basic views to display
themselves nicely.


The only other thing I can think of, is to allow CalendarEntries to be
crosslinked between different Schedules, and changed as one.  This would
allow, say a Meeting or Conference's Schedule to have a CalendarEntry which
also appears in a MeetingRoom's Schedule.  This is technically possible in
the ZODB, but in practice, the issue of asking all the Schedules to approve
a change before committing, is a bit tricky.  If it could be done, however,
it would be a *way* cool thing.  Not that all the preceding isn't pretty
cool on its own.


>gotta admit that a lot of my bias towards the rdb is based on the fact
>that mysql (our weapon of choice) has proven itself to be an incredible
>speed daemon (i mean, they sacrifice transactions, which i don't need, 
>in the name of speed). 

Interestingly, you *can* do transactions in MySQL, if you do them at a
higher semantic level.  For example, you could build a ZODB Storage
implementation based on MySQL that supported Zope versioning and undo as
well as transactions, all without MySQL needing transactions.  Of course,
arguably what you'd have when you did that would not really be a relational
database at all... :)