[OPEN-ILS-DEV] Christmas vacation and EG add-ons

Bill Ott bott at grpl.org
Sat Dec 22 13:09:03 EST 2007


> We may've talked also about re-vamping the whole notification system
> to allow easy "plugin" development as new communication media comes
> along (although, this may've been just me dreaming again... I don't
> remember).  I mean, current notification media might include E-Mail
> (already in place), Voice Phone, VoIP, IM, SMS, pager, etc.  Even in
> just the IM category, we have several protocols (OSCAR [AOL], MSN,
> Yahoo, Jabber, SILC, IRC...).  
>   
There are some notes on the wiki (scratchpad: notification) but it's 
just some brain storming if I recall correctly.

SMS and pager providers often have email interfaces for these services, 
so I would think that could be a short trip.  IM presents some similar 
issues as telephony in regard to verification of message delivery.

As the ultimate quick-n-dirty, I could have something working today 
based on a Windows application that will dial based on data from an .xls 
sheet.  A quick trip to reporter will give me that, but it doesn't help 
on the customer service end when you go looking to see if a notice was 
delivered.

Telephony offers some issues not found with email.  For instance, an 
early bird checking in items and triggering an email hold at 7:00AM is a 
good thing.  A phone call at that time probably isn't.  So, you're 
dealing with batch data.  Then there's the call result.  RFPs spell out 
pretty well how an SMTP server deals with delivery failures, retries, 
etc. In telephony we're talking busy signals, no answers, fast busy, 
error tones (e.g. Da-Do-Da "I'm sorry, your number can not be completed 
as dialed...").  How long should we wait between calls if busy?  How 
many times should we retry?

Then there's LATA issues with calling.  Let's take PINES.  One telephony 
server would make how many calls?  Between how many different LATAs?  
Our current telephony server makes 300-500 calls a day for only our 
system.  Toll charges can add up quick...  So, distributed servers 
calling for specific regions are useful.

You are correct that dial-in service for renewals, etc. is also 
popular.  This requires much tighter integration with the ILS, as you're 
dealing with authentication and real-time data.  This is also where 
Asterisk comes to mind, as it has the pieces available for phone 
tree/application type service.  I'm not familiar with it, but it also 
has some kind of Jabber interface, not sure if that could be useful.

I agree that notification overall has a lot of possibilities, but I have 
some selfish motives in regard to telephony, as I'm seeking to replace 
something existing, and that would be quickly missed if not available.

A notification API using the previously discussed interface, was it 
OpenSRF over HTTP (?), might fit the bill well.  Again, I'm just 
starting to poke at possibilities.  I've operated 2 different telephony 
servers for ILS notifications, and have seen some good and bad with each.

...back to vacation.





More information about the Open-ils-dev mailing list