Re: [OPEN-ILS-DEV] SIP2: Unexpected Results from Patron Info Request (Msg 64)
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: [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [OPEN-ILS-DEV] SIP2: Unexpected Results from Patron Info Request (Msg 64)
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: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] SIP2: Unexpected Results from Patron Info Request (Msg 64)
On Wed, Apr 23, 2008 at 11:38 AM, Bill Erickson [EMAIL PROTECTED] 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. Indeed. I don't remember checking out a book called 23423400234... 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... I think this is perfect. sip2.display.item_info.type = (title|barcode|...) or similar and have the SIP2 driver investigate that setting. -bill -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com -- Mike Rylander | VP, Research and Design | Equinox Software, Inc. / The Evergreen Experts | phone: 1-877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://www.esilibrary.com
Re: [OPEN-ILS-DEV] SIP2: Unexpected Results from Patron Info Request (Msg 64)
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: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] SIP2: Unexpected Results from Patron Info Request (Msg 64)
On Wed, Apr 23, 2008 at 12:19 PM, David J. Fiander [EMAIL PROTECTED] 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: [EMAIL PROTECTED] | web: http://esilibrary.com -- Mike Rylander | VP, Research and Design | Equinox Software, Inc. / The Evergreen Experts | phone: 1-877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://www.esilibrary.com
[OPEN-ILS-DEV] SIP2: Unexpected Results from Patron Info Request (Msg 64)
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: [EMAIL PROTECTED] [EMAIL PROTECTED]
