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

[David J. Fiander]

 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.

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.

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