[OPEN-ILS-DEV] PATCHES: OpenNCIP (Attn: David) and OpenILS::SIP

[Bill Erickson]

On Wednesday 18 June 2008 5:20 Brandon W. Uhlman wrote:
> Hi, all.
>
> Attached are two patches for SIP2 support in Evergreen -- one to the
> OpenNCIP server module that speaks to external services, and one to
> OpenILS::SIP, Evergreen's connecting glue between OpenNCIP and the
> OpenSRF-y underbelly.
>
> First, due_dates.patch makes some relatively trivial changes to
> MsgType.pm in OpenNCIP.
>
> Due dates being returned by the ACS to the SC outside the
> handle_checkout() method were in a different format than those being
> returned by handle_checkout(). Specifically, handle_checkout()
> returned the due_date result direct from the SIP interface (in our
> case, Evergreen). The other due_dates (for example, in handle_renew)
> were trying to be parsed through SIP::timestamp(), which expects a
> Unix timestamp, and was getting an EG due date string. It would fail
> being parsed, and the SC would get a duedate of 1969-12-31 (or so)
> back instead.
>
> The SIP2 standard specifically says that the ACS 'can send this date
> field in any format it wishes'. Since the format currently being
> returned by Evergreen and used in handle_checkout seems to be working
> with most SCs, and since I like consistency, I elect to use that
> format. Larry Wall once said about Perl, "it generally does what you
> want, unless what you want is consistency." We can do better. :)

I agree with the spirit of this patch, but I'll let David comment on it in 
case he has any grand schemes I'm not aware of.

>
> My second patch resolves a problem where some SCs expect message 64,
> the Patron Information Request, to return item barcodes instead of
> item titles when asking for a list of charged/overdue items, so that
> the results can be used in an Item Information Request to ask the ACS
> for more information about the item.
>
> This patch introduces a new configuration stanza, <options> in the
> implementation_config of an institution in oils_sip.xml. Currently,
> the only option is 'msg64_summary_datatype', which can have a value of
> 'barcode', which causes message 64 responses to return item barcodes
> instead of item titles, the previously default behaviour in
> Evergreen's SIP2 implementation. Setting any value other than
> 'barcode', or not setting this value at all will result in message 64
> returning titles.

+		if($return_datatype[0]->{value} ne 'title') {
+			push( @o, __circ_to_barcode($self->{editor}, $circid));
+		} else {
+			push( @o, __circ_to_title($self->{editor}, $circid));
+		}

In this case, if the option is not set, then it will return a barcode.  How 
about we change that first test to:

if($return_datatype[0]->{value} eq 'barcode') { ...



> The patch updates both the sample oils_sip.xml configuration file, and
> Patron.pm in the SIP2 implementation, where the charged_items()
> lookups are made.
>
> These patches may not qualify as SIP2-fu, but they are little steps
> toward making the default shipping configuration of Evergreen a little
> bit more humane, which I think is a desirable thing.

A worthy goal ;)

>
> DCO included, just in case these aren't trivial.

Thanks for the code, Brandon.  I'd qualify these as anything but trivial.  
I'll let you comment on my statement above, then get these committed.

-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