[Chandler-dev] Notification Architecture Proposal
randy at osafoundation.org
Wed Mar 19 08:26:32 PDT 2008
Thanks Brian for writing this up. I know it was tough to get back into
the cosmo codebase, as a lot has changed.
Brian Kirsch wrote:
> * Adding the ability for a user to specify his or her timezone during
> the sign up process and the ability to change that timezone in the
> Account Preferences.
This can also be used by other widgets.
> * Creating two new Atom projection URI's to support notification
> changes and forward notification queries.
The 'changed' projection makes sense as it just returns all changes in a
given time period. For the 'range' projection, it looks like only
events and items with reminder times are returned. So if alarms aren't
shared, that means only events will be returned. Is that right?
> * Augmentations to the Service layer to
> based on a time range return all items in a collection that have a
> start time (events) or reminder time (alarms) that falls with in the
> based on a time range query for a collection return notification
> objects that represent the changes per item with in the range.
> Record in real time changes made to an item or a collection (via a
> Hibernate / Spring abstraction) to modification database tables
> including the previous and current values.
I don't think we will be able to record per attribute changes without a
lot of other work first. I do think we need to start recording per item
changes such as item created/edited/deleted along with who did the
change and when. This will not only be useful for the 'changed'
queries, but in general auditing and reporting. So I propose to record
per item changes in the first phase, and then per attribute changes in
> * Expanding the User Preferences logic to store settings for push
> based listeners (EMAIL, SMS, XMPP) including which collections to
> push, the type of notifications (forward or modifications), and how
At first I thought we could store this as simple user preferences
(key/value pairs), but its probably better to persist them as separate
user properties that can be optimized for queries. Although as a first
pass it might be better to stick with user preferences as no protocol
work would be required.
> * Incorporating a Job Scheduler in to the Cosmo Architecture. The
> Scheduler will have jobs that awake at specific intervals, determine
> which users want notifications, query the Service layer, and pass the
> results to registered listeners (EMAIL, SMS, XMPP).
Now this is the fun part :) I think we will need more than an hourly
scheduler as explained on the wiki page as there are timezones with
offsets that aren't multiples of an hour. I'll have to think about this
more, but there is a lot of room for optimization here. I think we may
need some internal events that can be subscribed to. For example when a
user preferences change, an event needs to fire which is heard by the
job scheduler, which would update that user's schedule. As a first pass
we could even do something like reload the scheduler every 15 minutes to
pick up changes.
> * Adding new tables to the Cosmo schema and wrapping the database
> insertion and query logic in a Hibernate / Spring abstraction layer.
> The tables would persist changes to items / collections as well as
> additions and removals. The appropriate table columns would be indexed
> for fast query of modifications made in a given time range.
I like this idea and it would be pretty straight-forward to do as an
aspect that wraps each service call. I see this table as a generic
event table that can also be used for auditing and reporting.
I'm going to go ahead and try to break everything up (at least the
server work) into tasks and I guess we'll go from there.
More information about the chandler-dev