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
