[OPEN-ILS-DEV] Notification system design

[Mike Rylander]

On 12/21/06, Josh Stompro <stomproj at larl.org> wrote:
> Are there any design docs or wish list on how Evergreen handles various
> types of notices and delivery methods, and how they will work together?
> If not could I start one?  I am incredibly frustrated with the
> notification systems of the other ILS's I have worked with and would
> like to help design the "Notification Of Triggers Customer Resource
> Announcement Process - Evergreen" system, or NOTCRAP-E system for
> short.  The name could probably use some work though.

AAAAAAAAAAAAAAAAAHAHAHHAHAHAHAH... holy moly... ahhhh.  Man, that name
... whew! ... it just kinda snuck up on me, and then POW!  It's a
perfect working title, methinks.

There are no design docs for the notification infrastructure as yet.
This was nearly all Bill's stuff, so I don't know how far we should go
while he's not around to defend himself ;), but a generalized
notification service is something we've discussed (and makes sense, if
more than email notification is desired).

There are two competing types of "triggers" we'll need to consider
here:  real-time, action based triggers (hold arrives at its
destination; fine is generated on an overdue item), and time span
expiration triggers (item is 14 days overdue; hold fulfillment is
taking forever, would you like to try other formats/editions?).

The first of those, in our experience, is served well by a full
fledged OpenSRF service.  An example of this is the penalty server,
where any change to a user's circulation, hold, or fine standing
causes a recalculation of their penalties (blocked, delinquent, etc).
The second type, examples of which are the current overdue notices and
collections listing, is usually handled by a nightly process.  Both
end up in some sort of notification to someone, and collecting them in
a pluggable service sound like a good idea to me.

Some things to think about:

* we'll need a persistence model -- if reporting on notifications is
desired then it should probably be rolled into the central database
schema

* should there be two service types  -- "action" triggers and
"scheduled" triggers -- or should there simply be a polling process
that fires time-based events, OR should all be scheduled allowing for
a delay in "actions" (for example, a held item arrives but is damaged
and can't fulfill the hold -- so no notification should be sent)

* where do we delimit plugins -- should there be plugins for both
accepting/recording events and firing/performing notifications

>     I know where the email notification files are at now, and I see that
> automated phone notification is on the feature list for a future
> release, is there anything about how it all is going to be tied
> together, or about what events trigger notices, and about other forms of
> notification (SMS, IM, Telegraph, Smoke Signals, Exchange Calendar
> Events, etc).

The nice thing about email is that there are gateways from it to other
services like IM and SMS.  Even a phone notification system could use
text-to-speech to allow an email gateway, I think.  (Asterisk may even
have this today ... not sure.)

Hmm...  It's not a server-side notification thing, but a feed-based or
RESTful infrastructure for events is a very interesting idea.  Like an
iCal generator for a patron's current checkouts, perhaps?

> Josh
>
>
>


-- 
Mike Rylander
mrylander at gmail.com
GPLS -- PINES Development
Database Developer
http://open-ils.org