| Time |
Nick |
Message |
| 02:06 |
|
dbwells_ joined #evergreen |
| 02:14 |
|
berick joined #evergreen |
| 03:40 |
|
gsams_ joined #evergreen |
| 08:02 |
|
ericar joined #evergreen |
| 08:40 |
tsbere |
gah |
| 08:40 |
tsbere |
Since when do we have 37 novelist codes!?!?!? |
| 08:41 |
|
mmorgan joined #evergreen |
| 08:41 |
* tsbere |
remembers when there were only 12 or so a few months ago, and now he has to look into a slowness issue and figure out which codes are problematic |
| 09:01 |
|
mrpeters joined #evergreen |
| 09:02 |
|
bos20k joined #evergreen |
| 09:09 |
|
Dyrcona joined #evergreen |
| 09:14 |
|
kmlussier joined #evergreen |
| 09:32 |
|
jvwoolf joined #evergreen |
| 09:40 |
jvwoolf |
Hi folks! Is anyone out there using the Novelist On the Shelf product? |
| 09:41 |
Dyrcona |
MVLC is. |
| 09:41 |
Dyrcona |
Indiana is. |
| 09:41 |
JBoyer |
That we are. |
| 09:42 |
jvwoolf |
Can I ask how you are getting your records to EBSCO? |
| 09:43 |
|
yboston joined #evergreen |
| 09:45 |
Dyrcona |
tsbere might have changed it, but I wrote something in Java years ago. I used Java for various reasons, but mainly because it needed to run on Windows or Linux and be able to talk to Sybase or Postgres, eventually. |
| 09:45 |
Dyrcona |
I recently adapted it for On the Shelf. |
| 09:45 |
JBoyer |
We have a simple script that's run on a schedule to pull out the information they want and then FTP it to them. Dyrcona has a more fleshed out script available but you're welcome to borrow ours if needed. |
| 09:46 |
* tsbere |
stopped his rewrite when other things came up <_< |
| 09:46 |
Dyrcona |
JBoyer: I would suggest changes to the SQL query. |
| 09:46 |
tsbere |
Like On the shelf breaking certain records in the staff client, which is my issue today. :( |
| 09:46 |
Dyrcona |
tsbere: Well, that's not good. |
| 09:47 |
jvwoolf |
That's...discouraging |
| 09:47 |
JBoyer |
Dyrcona: I don't doubt it. I haven't looked at it since it was written. I just know that it seems to spit out what they want and I stopped looking into it. :-/ |
| 09:48 |
JBoyer |
Today's adventure is teaching NCIPServer to return the barcode of the targeted copy in the RequestItemResponse. |
| 09:48 |
Dyrcona |
I'd recommend using force_to_isbn13 on the ISBNs instead of the regex magic you're doing now. |
| 09:48 |
JBoyer |
Oh, yeah; when did that make it in, 2.9 or 10? |
| 09:49 |
|
rlefaive joined #evergreen |
| 09:49 |
Dyrcona |
JBoyer: Um, what? They should be able to place a hold via bib# and with the location in the message, NCIPServer will limit that to copies from the selected org unit. |
| 09:49 |
JBoyer |
(or before, because attention spans...) |
| 09:49 |
Dyrcona |
I think that has been there for a while. |
| 09:50 |
JBoyer |
But the response is supposed to have ItemId information, and whatever value is returned is assumed to be the barcode of the item. |
| 09:50 |
JBoyer |
That is what I was running into yesterday. The "fix" is to scan the barcode of the copy in hand when changing a request to Shipped. |
| 09:50 |
Dyrcona |
JBoyer: That is not how it works here in MA with the same vendor. (I can't remember their name.) |
| 09:50 |
JBoyer |
Or return item information in the itemid field instead of bib information/ |
| 09:50 |
tsbere |
JBoyer: I would assume that you *can't* provide a correct barcode until the hold hits "captured" >_> |
| 09:51 |
Dyrcona |
Well, he could if he places a copy hold, but that's not what you really want. |
| 09:51 |
JBoyer |
You can assume that the targeted copy (requests are only sent if items are available) will likely be the one captured unless the hold targeter is set too aggressively. |
| 09:52 |
JBoyer |
And they can always change that barcode too, but I want to have a "best guess" in the request that they /can/ change vs. a bibid that they /must/ change. |
| 09:53 |
JBoyer |
jvwoolf, I'm sorry I drug things off course, did you need an example of what Dyrcona or I are running or are you still researching options? |
| 09:53 |
Dyrcona |
Well, patch are always welcome. |
| 09:53 |
tsbere |
JBoyer: "Must" would, IMO, be better here. They build it into the workflow. Compared to "normally don't, but sometime needs to be changed" where they are more likely to ignore it because they don't normally touch that... |
| 09:54 |
Dyrcona |
Honestly, NCIP sucks. It's another "standard that isn't." |
| 09:54 |
JBoyer |
Dyrcona, Understood, and that's what I'm hoping to do (I also want to talk them into allowing proper passwords so that can be checked, but I'm not holding my breath...) |
| 09:55 |
JBoyer |
tsbere, That would be fine if it were common across implementations, but it sounds like most other ILS's NCIP connectors already do this, so it's another required step on our end vs an optional step for others. |
| 09:55 |
mmorgan |
JBoyer: Dyrcona: Our users have to scan in the barcode when shipping. It would be a huge improvement if they were not rquired to do that. |
| 09:56 |
Dyrcona |
mmorgan: That's the same for everyone on Evergreen, and I agree for the most part, but the best solution is to place a copy hold, and nobody liked that. |
| 09:56 |
tsbere |
JBoyer: And why does it matter if it is "optional" (but still needs to be checked from my understanding) when connecting to another ILS? Do your users frequently do this work across 5 different systems? |
| 09:58 |
Dyrcona |
tsbere: It's also a case of vendor laziness or some stupid herd mentality: "It works this way with every other ILS. Why do you have to be different?" |
| 09:58 |
jvwoolf |
JBoyer: I would love to see some examples. |
| 09:58 |
JBoyer |
It's a minor timesavings (that adds up) that other users are granted that we're not. I would prefer there be tighter 2-way communication to make this a lot better than NCIP currently is, but as it is I want NCIP to be as friction-free as possible. |
| 09:59 |
JBoyer |
Dyrcona, Also, the RIR specifies that it returns *Item* information, the values currently returned are from a BibliographicIdentifier* field. |
| 09:59 |
tsbere |
JBoyer: The way I see it, the *best* answer would be "ask the ILS for the barcode is at the stage where it is known to have been captured" at which point you have a specific copy. >_> |
| 09:59 |
tsbere |
But that requires changes on both ends |
| 10:00 |
JBoyer |
I'll send you a corrected version using the force_to_isbn13 function that Dyrcona mentioned, it's much less brittle than what we've been doing. |
| 10:00 |
Dyrcona |
tsbere: Unfortunately, NCIP doesn't work that way. Oh, wait, NCIP doesn't work.... There, fixed it for myself. |
| 10:00 |
Dyrcona |
jvwoolf: I can probably share MVLC's db query. |
| 10:00 |
JBoyer |
tsbere, yeah, that's got to be a 2-way thing, which I'm not aware of any decent 2-way library "standards" it's all 1 or 1.5 way. :-/ |
| 10:01 |
Dyrcona |
I'm not aware of any decent library standards, full stop. ;) |
| 10:01 |
jvwoolf |
Dyrcona: That would be great! |
| 10:01 |
Dyrcona |
Imagine if the same committees designed TCP/IP.... |
| 10:02 |
jeff |
greetings. |
| 10:05 |
kmlussier |
Hi all! Would there be any interest in scheduling a dev meeting next week since it appears as if there wasn't one at the regularly-scheduled time yesterday? |
| 10:06 |
* kmlussier |
is just back from vacation and catching up on IRC logs. |
| 10:06 |
pastebot |
"Dyrcona" at 64.57.241.14 pasted "jvwoolf: MVLC's DB Query for Novelist On the Shelf" (13 lines) at http://paste.evergreen-ils.org/10 |
| 10:08 |
jvwoolf |
Dyrcona++ |
| 10:08 |
pastebot |
"JBoyer" at 64.57.241.14 pasted "Basic Novelist script for jvwoolf" (56 lines) at http://paste.evergreen-ils.org/11 |
| 10:11 |
Dyrcona |
Has anyone tried the Linux client on a Chromebook? |
| 10:11 |
Dyrcona |
I imagine that it does not work. |
| 10:12 |
dbs |
Dyrcona: I think that could only work if you used Crouton or the like to actually run Linux on it |
| 10:13 |
jvwoolf |
JBoyer++ |
| 10:13 |
Dyrcona |
dbs: Thanks. |
| 10:13 |
jeff |
Yes, you'd need a linux environment (either chroot or dual boot), both of which I believe require turning off the normal safeties first. |
| 10:15 |
jeff |
Current options on a Chromebook include the web staff client, VNC/RDP using a Chrome app or HTML5 client like Guacamole, or the Citrix receiver with all of the infrastructure and licensing that that implies. |
| 10:17 |
* tsbere |
has an idea to prevent novelist, in general, from "breaking" the staff client the way it appears to be.....but has to reinstall things on his dev machine to test |
| 10:17 |
tsbere |
If it works I will throw it at Launchpad though |
| 10:17 |
jeff |
Another option is the Amazon WorkSpaces client, in which you still pay a cost but the infrastructure and management of same is included. :-) |
| 10:21 |
* dbs |
still holds out hope for webby |
| 10:21 |
dbs |
gotta get through this database upgrade though first :/ |
| 10:30 |
|
sciani joined #evergreen |
| 10:39 |
tsbere |
My proposed solution to the Novelist On the Shelf breaking things in the staff client issue: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/tsbere/delay_novelist |
| 10:46 |
|
brahmina joined #evergreen |
| 10:50 |
dbs |
jeff++ |
| 11:01 |
Dyrcona |
tsbere: Are you going to make a launchpad bug for the Novelist issue? |
| 11:01 |
Dyrcona |
Also, any particular reason to pick 100? That's seconds, right? |
| 11:02 |
tsbere |
Dyrcona: I was planning on doing so, but I was waiting to see if anyone had a comment (like "no! never do that!") |
| 11:02 |
tsbere |
Dyrcona: Milliseconds |
| 11:02 |
Dyrcona |
OK on both counts. I hadn't looked up the documentation for setTimeout(). |
| 11:02 |
Dyrcona |
I don't see why it would be a problem. Just means the Novelist information won't load, correct? |
| 11:03 |
tsbere |
Won't load for a tenth of a second or so, yea. |
| 11:03 |
Dyrcona |
"It" being setting a timeout. |
| 11:08 |
miker |
tsbere: +1 to a setTimeout, and (depending on how each browser implements that) having a value > 0ms could be a benefit. (time-based queue, and our own stuff delayed with 0ms timeout but lexically after the novelist stuff) |
| 11:09 |
tsbere |
miker: I have actually had issues with setTimeout and 0ms in the past (years in the past at this point, so may not actually be an issue anymore, but still...), to the point where I generally always put 1ms or greater anyway |
| 11:09 |
* miker |
glares at old IE |
| 11:11 |
* tsbere |
picked 100ms in part as a "hopefully any staff stuff can finish in 100ms, but that isn't likely long enough for an end user to scroll down to the Novelist area |
| 11:24 |
|
Christineb joined #evergreen |
| 11:28 |
* tsbere |
has filed bug 1609859 |
| 11:28 |
pinesol_green |
Launchpad bug 1609859 in Evergreen "Novelist delays can cause Staff Client issues" [Undecided,New] https://launchpad.net/bugs/1609859 |
| 11:53 |
jeffdavis |
Not sure if anyone else is seeing the same slowness with SRU/Z39.50 server that we've been experiencing, but bug 1609556 has a fix for the issue - pulling scoped holdings from the db via unapi rather than a (slow) supercat API call |
| 11:53 |
pinesol_green |
Launchpad bug 1609556 in Evergreen "SRU/Z39.50 slowness when retrieving holdings" [Undecided,New] https://launchpad.net/bugs/1609556 |
| 12:00 |
|
bmills joined #evergreen |
| 12:01 |
dbs |
jeffdavis: i eyeballed the diff yesterday; looks good! although it might not be a bad idea to keep some of the comments around the specific holdings config that we're trying to generate there as a possible guide to future devs |
| 12:06 |
|
jihpringle joined #evergreen |
| 12:07 |
bshum |
jeffdavis++ # I feel the need, the need for speed! |
| 12:08 |
jeffdavis |
dbs: yes, good call. That URL (http://vdxipedia.oclc.org/index.php/Holdings_Parsing) is dead and unarchived though, and I'm not sure what content it was referring to. |
| 12:09 |
dbs |
ah crap. |
| 12:09 |
dbs |
oclc-- |
| 12:10 |
jeffdavis |
the referenced format also returns no Google hits except for EG related stuff. |
| 12:13 |
Dyrcona |
jeffdavis: We've conversed about the slowness before. I never really looked into it because time. |
| 12:14 |
Dyrcona |
jeffdavis++ # for patches. |
| 12:14 |
* dbs |
looks at http://www.loc.gov/marc/holdings/hd852.html as a possible references |
| 12:15 |
Dyrcona |
Dyrcona-- # not saving changes to a script before trying to run it again. |
| 12:17 |
|
mrpeters joined #evergreen |
| 12:17 |
Dyrcona |
I can see why Ansible exists. Trying to prevent variable interpolation on the server with twice quoted local strings is a bit of a mess. |
| 12:18 |
jeffdavis |
dbs: hmm, looks like whatever supercat was doing previously in 852 (which I mindlessly imitated) is not quite conformant with that, perhaps this is a good time to fix that |
| 12:19 |
jeffdavis |
I'll tweak that a bit and push another commit to the branch |
| 12:22 |
dbs |
jeffdavis++ |
| 12:23 |
dbs |
IIRC though, the requirements will likely differ based on whatever ILL service you might participate in; in our case, we needed something that conformed to what VDX wanted from SRU/Z39.50 at the time |
| 12:27 |
jeffdavis |
MARC is like a can of worms, and each worm is wrapped around another, smaller can of worms. |
| 12:27 |
dbs |
ah, looks like OCLC hid their documentation behind a "support email" wall: https://www.oclc.org/vdx/resources.en.html |
| 12:27 |
dbs |
sigh |
| 12:35 |
|
bmills joined #evergreen |
| 12:35 |
|
bmills joined #evergreen |
| 13:16 |
|
gsams joined #evergreen |
| 13:47 |
Dyrcona |
@quote add <jeffdavis> MARC is like a can of worms, and each worm is wrapped around another, smaller can of worms. |
| 13:47 |
pinesol_green |
Dyrcona: The operation succeeded. Quote #156 added. |
| 13:48 |
Dyrcona |
@quote random |
| 13:48 |
pinesol_green |
Dyrcona: Quote #111: "< RoganH> Obviously they weren't from the south or they would have tried deep frying it." (added by csharp at 12:22 PM, April 15, 2015) |
| 13:48 |
gsams |
somehow appropriate |
| 13:48 |
Dyrcona |
Deep fried worms.... ;) |
| 13:48 |
|
_bott_ joined #evergreen |
| 13:49 |
gsams |
I just finished helping a cataloging class... It was kinda like a deep fried can of worms, etc. |
| 13:49 |
Dyrcona |
gsams++ |
| 13:51 |
Dyrcona |
The quote from jeffdavis would make a nice blame, too. |
| 13:52 |
JBoyer |
Dyrcona: I've been thinking, with the last NCIPServer commit to master nearly 2 years old, would it be best to just merge user/dyrcona/better_abstraction into master and move on from there? Are there concerns that it breaks koha? (who are free to keep using the version last touched 2 years ago...) |
| 13:52 |
Dyrcona |
It breaks Koha. I completely changed the interface. |
| 13:52 |
JBoyer |
ok. |
| 13:53 |
gsams |
Dyrcona++ #I agree |
| 13:53 |
jeff |
finding someone with time and interest to propose a koha patch that works with the better abstraction would likely keep everyone on the same page. |
| 13:53 |
Dyrcona |
JBoyer: That said, I'm not sure who (beyond MassCAT) on Koha uses it nor where they get it. |
| 13:53 |
JBoyer |
Perhaps a koha_support branch that can just sit there until someone has time to rebuild their interface since it appears no one cares about it either way at the moment. |
| 13:54 |
JBoyer |
jeff, true, but finding someone to care may be the trick. If no one cares if it works with koha I'm not going out of my way to care for them. |
| 13:54 |
Dyrcona |
jeff JBoyer: rangi and I sometimes say, "Yeah, we need to merge to those branches." |
| 13:56 |
Dyrcona |
I was going to say that rangi might be around in a few hours, but he could be at the Koha-US conference. |
| 13:56 |
Dyrcona |
It's about 6:00 am Friday in Wellington if he's at thome. |
| 13:57 |
Dyrcona |
If he says its OK, I'll just clobber master the the better_abstraction branch. |
| 13:57 |
Dyrcona |
That first "the" should be "with." |
| 13:58 |
Dyrcona |
JBoyer: I got an email after we chatted earlier, and I may make some changes to the LookupUser handler, but I don't know, yet. |
| 14:19 |
JBoyer |
What kind of LookupUser changes? I just heard of another change it might need, unless we're both talking about limiting successes to FromAgencyId = $user->home_ou->shortname |
| 14:22 |
JBoyer |
Dyrcona: I think I'm also going to tweak RequestItem so that if the request user home ou != the home ou of the ncip user it ignores selection_depth, allowing "regular" holds for items in your lending 'network' That's a handy feature that's already close to working as expectegd. |
| 14:22 |
Dyrcona |
JBoyer: We talked about allowing that, but didn't in the end. |
| 14:25 |
JBoyer |
It already works without any special handling except that it still limits selection_depth to your home ou. Would there be any issue with making it work that way since libraries can still disable ncip holds in the participant record? |
| 14:25 |
JBoyer |
If they wanted to turn that off, that is. |
| 14:26 |
|
mrpeters joined #evergreen |
| 14:27 |
Dyrcona |
I don't think it would be a problem. I'm not sure how the holds then interact with the ILL software, but A-G does have a provision for that. |
| 14:28 |
JBoyer |
They get placed and then the request on A-G |
| 14:29 |
JBoyer |
's side is just dumped. It looks like it works as close to "as expected" as something so roundabout could. |
| 15:04 |
|
mmorgan1 joined #evergreen |
| 15:39 |
|
mmorgan joined #evergreen |
| 16:03 |
kmlussier |
berick++ #Web client fixes |
| 16:39 |
|
bmills joined #evergreen |
| 16:50 |
Dyrcona |
Ah, JBoyer left. |
| 16:51 |
* Dyrcona |
just talked to rangi. |
| 16:53 |
Dyrcona |
NCIPServer could really use some documentation. |
| 17:05 |
|
mmorgan left #evergreen |
| 17:42 |
berick |
neat. just click-held the reload icon in Chrome and it gave reload / cache clearing options. never noticed that before. |
| 17:47 |
|
jamesrf joined #evergreen |
| 20:07 |
|
jihpringle_ joined #evergreen |
| 23:18 |
dbs |
berick: huh, not seeing that in chrome-beta on linux. i know shift-reload deploys additional cache-clearing powers though |
