[OPEN-ILS-DEV] SIP2: Unexpected Results from Patron Info Request (Msg 64)

[Mike Rylander]

On Wed, Apr 23, 2008 at 12:19 PM, David J. Fiander <david at fiander.info> wrote:
> From Brandon's report, it looks like the client he's dealing with expects a
> barcode, and knows that it needs to pass the barcode back to the ILS to get
> the human item information associated with that barcode.
>
>  Regardless, this change requires at least extensive consultation with the
> current user community, or a system-level configuration parameter (as Mike
> suggested), or both.

To be fair, Bill suggested it.  I just produced an example.

>
>  Don't get too carried away about suppressing the returning of holds
> information without further exploration either. My reading of the protocol
> is that the client may send a simple Patron Info Request to find out how
> many of each thing there is, and then follow up with a more complex Patron
> Info Request to get the details about a class of item. We _know_ that
> multiple PI Requests are necessary, since a single PI Response can only
> return info about one class of item.
>

I agree, and had skipped that part of the suggestion. I think we
should return all the data that the client asks for, no paging,
assuming the spec does not provide for paging.

>  Of course, if you already have log info indicating that clients (software)
> are stupid and asking for way too much info all at once, then go wild. It
> might make sense to say, "There are 53 holds outstanding," and then present
> a list of just the first 10, and count on the client (software, again)
> knowing enough to request further info if desired.
>
>  - David
>
>
>
>  On 23-Apr-2008, at 11:38 , Bill Erickson wrote:
>
>
> > David J. Fiander wrote:
> >
> > > Brandon,
> > > That makes sense.
> > > This probably hasn't come up before because there are few SIP clients
> that implement lots of enhanced functionality, like renewing and paying
> fines at the terminal.
> > >
> >
> > Right.  I can also see cases where the data is displayed to the user, in
> which case titles are a good thing to return.
> >
> >
> > > The code that handles what data gets put into the holds, overdue, etc,
> fields isn't in my SIP protocol code; it's part of the ILS backend module
> that I call.
> > > So, Bill's the one that decided to return the title, rather than the
> barcode.  Well, my test stub code returned titles, because that makes it
> easy to read the packets, and Bill just mirrored that.
> > > Either way, it's pretty straight-forward. you just need to edit the
> ILS::Patron::hold_items() function to return the right stuff from the patron
> record.
> > >
> >
> > In Brandon's case, we're talking about Patron::overdue_items() and
> Patron::charged_items(), though, right?
> >
> > Shortly, I'll be implementing an org unit setting to support the
> suppression of holds information in patron information requests.  (In the
> case where the client doesn't care about the holds information and a patron
> has 50+ holds, it's just passing around a lot of unnecessary data.)  Along
> those same lines, we could add an additional org unit setting to determine
> what data is returned from the overdue|charged_items() calls...
> >
> > -bill
> >
> >
> >
> > --
> > Bill Erickson
> > | VP, Software Development & Integration
> > | Equinox Software, Inc. / The Evergreen Experts
> > | phone: 877-OPEN-ILS (673-6457)
> > | email: erickson at esilibrary.com
> > | web: http://esilibrary.com
> >
>
>



-- 
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