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

[David J. Fiander]

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.

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.

- David

On 22-Apr-2008, at 21:30 , Brandon W. Uhlman wrote:

> Hi, all.
>
> I think this question is probably going to be for David Fiander,  
> mostly, if he still hangs out in these here parts. Maybe Bill or  
> someone else with some general experience with SIP2 (not  
> necessarily Evergreen) can provide some advice as well.
>
> The SIP Message 63, Patron Information Request, takes a number of  
> parameters, the most important of which is a patron barcode (AA).  
> In response, the ACS responds with a message 64, Patron Information  
> Response, which contains a bunch of information about the patron,  
> name, various circulation limits, and a list of the items currently  
> charged/overdue/on hold/etc.
>
> Currently, title information on these items is being returned  
> through a chain of  calls initiated by calling __circ_to_title().  
> Our SIP client vendor expects message 64 to return the item  
> identifier (barcode). Further information about the item (including  
> title) is received by issuing a message 17 (Item Information  
> Request), and receiving back message 18, Item Information Response.
>
> I think the SIP2 standard is poorly written enough that you can  
> return any piece of information about the item and still adhere to  
> it. The fact that a title can't be guaranteed to identify a  
> *unique* item, and that numerous SIP2 requests on the client side,  
> including msg 17 (info request) and 29 (renew) expect barcodes,  
> leads me to believe that message 64 should *return* barcodes where  
> it currently returns titles.
>
> Does anyone have any thoughts on this? If the general consensus is  
> that msg 64 should return barcodes, I can prepare and submit a  
> patch to that effect.
>
> Thanks,
>
> Brandon
>
> ======================================
> Brandon W. Uhlman, Systems Consultant
> Public Library Services Branch
> Ministry of Education
> Government of British Columbia
> 605 Robson Street, 5th Floor
> Vancouver, BC  V6B 5J3
>
> Phone: (604) 660-2972
> E-mail: brandon.uhlman at gov.bc.ca
>         brandon.uhlman at bclibrary.ca
>