[OPEN-ILS-DEV] Fine Generation Code Question

[Mike Rylander]

On Fri, Nov 21, 2014 at 2:23 PM, Galen Charlton <gmc at esilibrary.com> wrote:

> Hi,
>
> On Fri, Nov 21, 2014 at 10:48 AM, Dan Wells <dbw2 at calvin.edu> wrote:
> > The main problem with plan #2 is not the generation component of fine
> > handling, but all of the other possible alterations and adjustments to
> fines
> > which can happen depending on the checkin conditions.  I do agree that
> #2 is
> > better from a design perspective, but it is quite a bit more complex than
> > your outline suggests, and it would (in my opinion) be much safer to
> > approach that design iteratively, which is what I hope doing #1 first
> would
> > allow us to do.
>
> To toss in a use case to keep in mind, one of the things that I know
> some Evergreen sites have run into is a need to keep the time
> responding to a SIP2 checkin request short so as to not cause a sorter
> to route an item to the exceptions bin.
>
> For that use case, the sorter will need to know where the item goes
> next, which means that processing to determine if the item fills a
> hold request can't be deferred (although it perhaps could be
> simplified in the interests of minimizing exceptions), but the sorter
> wouldn't necessarily care about fine processing.
>
> On the other hand, at the circ desk itself, fine processing during
> checkin can't necessarily be delayed indefinitely, as a patron may
> want to pay their fines right away, but a small delay between checkin
> and reconciling the current fine state could be acceptable as long as
> it were presented well in the UI.
>
>
These are good points.  There may be a happy medium that gets us the best
of both worlds, however.

Perhaps we should use a streaming response to the client once checkin is
complete enough to know what routing information there is to know, and then
follow up with a complete (or exception) once the fine disposition is
handled.  For SIP, the Evergreen driver can respond immediately upon
receipt of the first message, ignoring the remainder, and the staff client
can update the UI as information flows back.  Then, the benefits of Dan's
Plan #1 are realized, and we gain reduced latency for SIP and friends.

Thoughts?

--
Mike Rylander
 | President
 | Equinox Software, Inc. / The Open Source Experts
 | phone:  1-877-OPEN-ILS (673-6457)
 | email:  miker at esilibrary.com
 | web:  http://www.esilibrary.com



> Regards,
>
> Galen
> --
> Galen Charlton
> Manager of Implementation
> Equinox Software, Inc. / The Open Source Experts
> email:  gmc at esilibrary.com
> direct: +1 770-709-5581
> cell:   +1 404-984-4366
> skype:  gmcharlt
> web:    http://www.esilibrary.com/
> Supporting Koha and Evergreen: http://koha-community.org &
> http://evergreen-ils.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20141121/077593dc/attachment-0001.htm>