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
