[Chandler-dev] Notification Architecture Proposal

[Randy Letness]

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 
> range.
> 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 
another phase.

> * 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 
> often.

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.

-Randy