Implementation of notifications
Events are generated by various parts of the system. For example adding an event to a calendar might generate two related events, an Entity Added event and a calendar modified event. Some of these events need to be persisted to ensure a reliable notification system. Persisting events is a characteristic of the listener rather than the event, for example we might want to log calendar modifications for statistical purposes, this does not require persisting those events. However, if we are watching for those events to email users we may need to persist that event.
The notification handling system should divide events up into queues. The criteria for determining which queue depend mostly upon what is taking things off the front end. For example, all events which might depend upon some email process should be on the same queue.
Queues will be held in memory - or at least the first n elements. When an attempt is made to add an entry to the queue it is discarded if it already exists on the queue. Some queues will impose a delay of at least a few seconds which allows multiple changes to be coalesced as one. For example, mailing calendar change events can be done at 15 minute intervals - multiple changes in that period should only cause one email. (A processor may keep a table of recent mailings per calendar to reduce that number even further).
Essentially we need a queue per listener.
When an event is generated and passed to the notification processing system it will be handed to a number of event processors. Event processors will register with the notification ssytem and indicate what types of event they are interested in and some other information used to select events. For example, a processor which mails out calendar change events for a particular calendar will register fro that type of vent and provide the path as a pattern.
System events will be queued up for all matching processors. Some events will be flagged as non-persistent. These will not be added to the database at any time. Others will be persisted as part of the transaction that created them.
Immediate v delayed processing
Processing of events which takes place immediately, as part of a request, can be handled by the web (caldav) application. Those which are persisted and processed later must be handled by some outboard process. In the jboss world it could be a system service of osme kind. Otherwise a system process needs to be started to handle the persisted event queue. This could be a cron job, or just some process started up which sleeps for some period when the queues are empty.
To avoid persisting events which are not interesting they should be passed through a listener which determines if anybody is interested. For example, calendar change events need long term processing. The outboard processor needs to delay sending of mail for a period, perhaps we only mail events every hour. If nobody is watching for changes on a calendar we just discard the event otherise, depending upon the listeners, we may persist it.