[OPEN-ILS-DEV] Notification system design

[Nathan Eady]

Mike Rylander wrote:

>> Oh, that, yes.  Some kind of record of what's been done is always
>> wanted.  
>> Surely, though, you must have something like that already.
> 
> We do.  

> I was just pointing in the direction of "do we retain all history by
> marking events 'complete'" or "do we remove events after completion."
> The former is, in some regards, simpler and gains us more in terms of
> reporting.  To me, the choice is self-evident ... but I wanted to
> bring up the options.

Ah, I see.

Traditional reporting, incidentally, might not be all you gain by
retaining such information.  There's also the potential, down the
line, for putting stuff like "People who check out C.S. Lewis also
read these authors..." in the PAC.

And even for reporting, the obvious uses aren't the only ones.
Weeding reports, for instance, might like to distinguish between
an item that has circulated three times in three years to patrons
who check out frequently, versus an item that has circulated three
times in three years, two of those times to patrons who only check
out occasionally.  The latter might be considered important, since
presumably it's something people are specifically looking for;
whereas, the former might just as well be replaced with a newer
item that would be just as appealing to the "regular customers".
Of course a human can look at the items and make a judgement
(the Nora Roberts paperback that circed three times can go, but
the Latin dictionary that circed three times should stay), but
it's always nice if the computer can give you a more narrowed
list to work from.

So yeah, my preference would certainly be to keep the information
in the database.

OTOH, I am certain some libraries would NOT want to have such
information stored.  Big city libraries, particularly, tend to
be quite paranoid about these privacy issues.  Some even argue
against allowing patrons to opt in to such retention, on the
grounds that patrons don't (or even can't) understand the risks.
(This extreme position is, in my view, totally insane, but I've
seen it argued, although I cannot now for the life of me find
exactly where.)

I know of at least one proprietary ILS that handles this in the
following fashion:  the information is stored in the database,
but the vendor officially says it isn't, and the staff client
does not expose it, and none of the canned reports expose it in
a personally-identifying way, and most librarians don't know
enough about databases to realize the inconsistency.  I don't
think it behooves an open-source project to do things quite
that way, however.

Perhaps it could be made a site option.  Indeed, perhaps deletion
of personally identifying information in circ records and so on
could be delegated to an optional overnight process.  I would
_hope_ that would be soon enough even for the militant privacy
advocates.

I no longer remember what this has to do with the design of the
notification system, though.

> I imagine the event system would absorb most of the current
> notification logic, but nothing other than that.

 > Just to clarify, nothing that requires real-time or transactional
 > (ACID) semantics can ever use this.  This new infrastructure would
 > absorb, at most, the current hold and overdue (including billing)
 > notification.  Any delayable events could (hopefully) be built on this
 > as well.

In that case, the notion that it would be simple seems more viable.
I wasn't so sure it would be, in practice, when I thought you meant
to include circulation-type events and so on, but if we're only
talking about notice generation and so forth, the worst complexities
can hopefully be avoided.

> When I mentioned circulation based events I meant events created by a
> circulation, not representing them.  Imagine an offer-to-review event
> that is generated on every 1,000th circ, or maybe on every circ of new
> books, or whatever.  The circ would generate an event, and the event
> processor would create and send the needed information (authorization
> token, email of the offer, etc).

Ah.