[OPEN-ILS-DEV] Send call number to SMS feature + licensing of

[Mike Rylander]

Wow, Josh.  Sorry for the delay in responding, but it took a little
while for that to sink in.  That's really awesome!  Some thoughts
in-line.

On 10/31/07, Josh Stompro <stomproj at larl.org> wrote:
> I would like to take a stab at adding a little feature to the web
> catalog interface, it should be fairly easy since I would just be
> modifying someone else's work.
>
> The feature is the ability to send call numbers via SMS from a detailed
> bib record display.
>
> Example Use:
> 1. A user that is more comfortable texting than writing things down
> comes into the library.
> 2. They use the catalog to find an item they want to grab from the shelves.
> 3. They click the "Send via Text Message" button.
> 4. A screen pops up where they enter their phone number and select their
> provider.
> 5. The call number is sent to their cell phone.
> 6. Repeat for a few more items.
> 7. They use their cell phone to find the items in the shelves.
>
> Adam Brin of Tri-Colleges PA ( Bryn Mawr, Haverford, and Swarthmore
> Colleges) created a way to do this with III catalogs and documented and
> released his code.  http://trilogy.brynmawr.edu/trico/sys/sms.html
>
> If anyone would like to see it in action try this link
> http://tripod.brynmawr.edu/record=b2462804  Click on Send via Text
> Message to try it out.
>

Nice choice of title. ;)

> Adam didn't attach a license to what he released.  I contacted him about
> using it and he said "if it's something you want to use, you have my
> blessing."  Is that enough of a release?
>

If he's willing to send you that in an e-mail with the DCO, that would
be ideal.  It would be placed under the GPL (or something compatible)
for Evergreen purposes (assuming he doesn't care about that), and he
(or his place of work, depending on any details there) would retain
original copyright of course.

> He was constrained by the fact that he had very little access to the
> catalog underpants, er backend, so he designed it so he could sneak it
> in with some javascript and a perl script on another server.  It could
> probably be more integrated with evergreen, but maybe it isn't needed.
> A users cell number and provider could be stored in their record, but
> that would require that they log in to use the feature, which they might
> not want to do on a public terminal to quickly send themselves a call
> number.
>

I think it could use their info if they are logged in for whatever
reason, but I love the ability to text directly without logging in.
We may have to make that configurable, though.

> Maybe this should be part of a larger "Sent to" interface which would
> support more methods. (To email, ...).  Currently the Actions menu
> doesn't show up unless someone is logged in, or else that would be where
> it would go.
>

That's something I was thinking about when I first started reading you
email.  We've discussed it before, but I do think it would be good to
think in that direction.

Just to dump what's in my head right now, I'm imagining a stalling
queue that would take in, say, an email-ish structure and an amount of
time to delay sending it (in seconds) and put that into the queue,
returning the unique identifier of the message.  Then a daemon would
wake up every few seconds, check the queue for messages that had
expired delays and send those out.

For this SMS piece it would always use a 0s delay, but for, say, hold
availability notification it might wait 10min to allow staff to
retarget the hold (and kill the notification) if the item was damaged.

>From what I've looked at with that code, I don't see any reason this
couldn't be used as the backend to the existing javascript (with some
minor adjustments, of course).  Also, such a queuing service should be
relatively simple to create, and needn't even be tied into the main
database.  I could see a singleton OpenSRF service that runs on just
one machine and has its own database configuration, and even its own
application namespace.  Eventually it could be moved into the core db
if it makes sense.

As for where the email templates come from, that's something best
handled at another layer, I think.

> Please let me know what you think.

I love it ... what do /you/ think? ;)  Is this something you'd like to
consider taking on?  I know the SMS part doesn't strictly need a
stalling queue, but it seems like a good opening to start work on it,
and having a central mailer, stalling or not, would be very useful for
other things as well.  And, other than the actual email sending logic,
the first cut would be mostly Adam's current code (I think).  Then we
could look at how best to migrate other parts into the system.

Eh?

Thanks Josh!

-- 
Mike Rylander
 | VP, Research and Design
 | Equinox Software, Inc. / The Evergreen Experts
 | phone:  1-877-OPEN-ILS (673-6457)
 | email:  miker at esilibrary.com
 | web:  http://www.esilibrary.com