This will allow applications to be notified of changes to calendars and their contents. This mechanism could become a central part ot the system. It allows many services to be built without modifcatiuon to bedework. We need a way for deployers to register event listeners which will be given access to events as they occur within the system. For example a new user event would allow a listener to setup a user according to some site specific requirements.
Some possible uses.
Web applications refresh and keep-alive
Rather than refreshing the entire display periodically, we can have a small ajax style component periodically checking a refresh flag. That flag will be set true when a callback is notified of changes to any of the users subscribed calendars.
There is some concern over the load placed on the server by caldav clients polling for changes. In the short term, requesting some sort of chnage property or etag on the collection might avoid a propfind on the entire collection. In the longer term, we probably want to use notifications through some, as yet undefined, channel.
Mailing of events
A mailing application can be informed of changes rather than needing to search periodically.
Public event submission
Mail admins when an event is submitted to a drop-box
Kinds of notification
It looks like we have following kinds of notification,
- Associated with active session, call back to some server side code
- Longer term, associated with a user
When a user sets a watch on a calendar they should be able to set certain parameters. In the short term we may not implement all but longer term they are probably worthwhile:
- Filters - e.g. only (or exclude) events with specified categories
- Frequency - We may want to allow a user to specify the frequency of notifications, 5 minutes for an important calendar, daily for less important.
If we're going to batch up notifications we need a notification queue. Do we store it in the db?
The session notifications should not be stored. They disappear with the session. Others probably should be and we do our own polling of the queue at a system specified interval.
For example, we may choose to only notify at 5 minute intervals so we fetch the pending next 5 minutes and when processed, delete.
We need to ensure that in incoming notification has actually been delivered, during the update we may get a stale state exception.
The notification entry needs to contain a timestamp for last notification. When we deliver we (may) deliver the changes depending upon the delivery method. Session notificatiuons probably just set a flag.
Some care needs to be taken when designing a notification system like this. One of the biggest performance problem for large Sakai installations is their event system, which puts a huge load on the database.
A notify class would define a request for notifications and would be associated with the object being watched. We need soemthing like the following:
- Transient - true if we don't store in the db - e.g. a session notification
- Period - a duration giving the delay between notifications
- last notification - a timestamp
- next notification - a timestamp
- who - essentially the owner
- how - how to notify
- what - what is the event - can we tie event alarms into this?
We should define a Listener interface which can be registered to listen for various events within the system. This would allow us to build hooks into the system for a number of purposes.
A notification listener would be called with information about the events we are looking for, for example, certain synchronization mechanism might need to know about changes to data.
A persisting notification listener might save these events in a queue for later use when synchronizing an external device. The information persisted might be which collection (if multiple collections), which entities were changed, which entities were deleted and which were created. The number of such entries is obviously limited to the number of entities which ever existed for the collection(s) being observed.