Forum OpenACS Q&A: Status of the Calendar module?

Collapse
Posted by Sondre Bjørnebekk on
Hi!

I noticed Ben Aida's message about working on the calendar these
days...  What is the current status of the package?  Is Ben's work
related to Tcl only or is it major changes in the datamodel?

As far as I can see the module does not support scheduling
directly?  (I.e. to answer questions such as on what time parties X,
Y and Z are available.)

How about aggregating multiple calendars (i.e. group and personal)
into a users personal calendar/agenda?  Is this supported in the
datamodel-layer or is this supposed to be built entirely in the app.
layer?

I am currently looking into the datamodel of calendar (and thereby
events). I noticed that calendar was not part of the core CVS
version (so I used the 4.5b1 download), is it in a separate CVS-
module?

I also noticed some (although dated) postings about major
performance problems in the module.  Are these sorted out or do they
remain in the current version (which I might not have...)?

We'll be happy to share our experiences with extending the
datamodel. However, as we'll do most of our work in Java in the app.
layer those parts wont't be directly useful for openACS on the code
level.

Regards from Norway,
Sondre

Collapse
Posted by Ben Adida on
Sondre,

I have not changed the data model recently, although I did add
calendar item types a few weeks ago. Mostly this has been a
thorough Tcl and SQL query cleanup. That said, the data model
could use some overhauling. I believe there are still
performance issues. I'm thinking that most of them can be
addressed by using correct indexes, but I will have to get back to
you on that with a full diagnostic in the near future.

In general, the calendar package's data model is a great
example of massive overdesign on one end, and massive
underdesign on the other. To create a calendar event, you have
to have two records that represent timespan, an activity record,
an acs_event record, and a calendar_item record. Then you
need a recurrence record if you want recurrence. So if you're
doing 5-way joins on every select, there are clear optimization
routes. Meanwhile, calendar_item *extends* acs_event instead
of simply mapping an acs_event to a calendar. This means you
can no longer extend the event type to make your calendar more
useful (Don hit this problem in working on the events module for
dotLRN).

So there are issues. I think in the short term, these issues will
be addressed with carefully built queries and judiciously chosen
indexes. In the medium term, a full rewrite of the data model is in
order. As soon as I recover from the pain of redoing the Tcl, I'll
take a look at the data model.

Collapse
Posted by Sondre Bjørnebekk on
Hi Ben, thanks for your quick response!

We have actually changed[1] the meaning of the calender item to be a straight many to many mapping between a event and calendar before reading your posting. This way the CI is no longer an acs_object and event becomes the (even more) central entity. We might add specializations of event later on.

We're probably also adding a specialized party called resource which will give us some support for sheduling directly via the mapping from parties to events.

I'll guess I'll run head on into the perfomance problems for now and then try wrestling with oracle indexes (and maybe app.layer caching, in our case Java) to speed things up after having tried to build something on top of the model.

For timespan/intervals the version of the pl/sql that I tested always creates an extra copy of every interval it uses for some reason (it is "documented" as being the app's responsibility -- I don't see any reason for doing it in the first place, however).

On the CVS-question:  Which module contains the most current version of calendar?

I'll try to post any experiences while working on it here if it is of any value to you guys.

-S-

[1] - On the drawing board, CI replaced with a 'eventcalendarmap'

Collapse
Posted by Arjun Sanyal on
Sondre, yes the calendar package is not part of the "acs-core" CVS module.
You can check the latest version from the development tree with:

cvs -d :pserver:mailto:anonymous@openacs.org:/cvsroot login

(hit return)

cvs -z3 -d :pserver:mailto:anonymous@openacs.org:/cvsroot co calendar

Collapse
Posted by Sondre Bjørnebekk on

Hi Arjun -- thanks! I've now downloaded (checked out) the calendard-module. The data model does not seem to have changed significantly from the one I downloaded (4.5b1).

Here are the comments I made about our changes to the data model in a document I've written on at times the past couple of days (hope it gives meaning even when copied from its context):

Changes from the ACS version

First of all: All table and package names are converted to our naming standard.

We have removed the CALENDERITEM of the ACS model as it was limiting the extendibility of EVENT and not adding any value. The table is replaced with a table EVENTCALENDARMAP which tells which events belong to each calendar. This also makes it possible to link a single event to several calendars which seems to be a good idea.

We have used the representation of a range of time intervals from ACS. However, we have moved this "one level up" so that TIMESPAN is related to OBJECT instead of EVENT. This is done to make reuse of service-layer code easier (scheduling maybe being the prime example). Since the EVENT has a is-a relationship to OBJECT this should not have any particular side effects (other than some minor changes in PL/SQL).

We will introduce a PARTY called RESOURCE which will make it easier to treat resources and users as equals when implementing scheduling. It will also make functionality such as "view the meeting room's calendar" as easy as viewing a user's calendar.

Collapse
6: Timespans (response to 1)
Posted by Sondre Bjørnebekk on
Regarding my comment on timespans, it might be craziness to move a possible association to the acs_object level (I do not think I want to join on the object-table more than necessary! :). So I'll probably not do that literally, rather try to write the code in a generic way so that it can be reused directly of other objects related to timespans.