Evergreen ILS Website

IRC log for #evergreen, 2014-04-11

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat

All times shown according to the server's local time.

Time Nick Message
00:17 Guest40233 I'm curious...what does Evergreen need to know about RDA?
00:17 Guest40233 ^bshum dbs
00:21 bshum dcook: Well, the thing we're working on is some new work to show more RDA 264 tag elements in the catalog.  Thing is, we don't have any sample bib records in our test dataset that ships with Evergreen that include 264 (or other RDA tags)
00:22 bshum dcook: dbs' idea is to get some sample bibs that do contain these new tags into our test dataset so that future testing / work with RDA can be checked using those test bibs.
00:22 dcook Mmm. Fair enough. I can certainly get behind that idea.
00:22 dcook It would be nice to have a quintessial RDA record set
00:22 dcook Man, that wasn't even spelled anywhere near correctly
00:23 dcook quintessential*
00:23 bshum Hehe
00:24 bshum Present time, Evergreen already supports generally the 264 publisher tag, but there's work in the mix to add other types of 264 - producer, manufacturer, distributor, and copyright date
00:24 bshum And we may have some bug fixing to deal with in how 264 was originally implemented now.
00:25 bshum Down the road, I don't know how ready we're going to be to work on other things, but we're starting simple.
00:25 dcook That actually sounds quite logical
00:26 dcook At first, I thought you might just be wanting a list of tags and I thought of: http://www.loc.gov/marc/bi​bliographic/ecbdlist.html
00:26 dcook Too bad it's just plain text and not XML...
00:26 dcook But yeah...having a set of RDA in MARC records to validate against would be wonderful.
00:26 dcook When I say wonderful, I mean less making you want to stab yourself in the eyes :p
00:27 bshum Heh
00:29 dcook I wonder if LOC indexes some of their RDA fields like 336, 337, 338
00:29 dcook A person could try doing an automated search on LOC for some RDA records and maybe put together a set that way
00:29 dcook Fairly haphazard but better than the alternative, perhaps?
00:31 bshum Potentially.
00:31 bshum I'll wait to see what dbs has in motion.  In the meantime, our live system has enough RDA bibs with 264 tagging floating around.
00:32 bshum Our consortium's been adding them for awhile now.  Part of the reason I feel very close to making sure it plays nicely.
00:32 dcook Always a good idea
00:33 dcook I wonder how useful this is: http://www.loc.gov/marc/RDAinMARC.html
00:34 dcook Anyway, I'll shut up now. I was just curious :)
00:35 bshum It's cool.  My brain is just slowly winding down as the day ends.
00:35 dcook Wait a tic..
00:35 bshum Those 3xx tags make me wonder though...
00:35 dcook Wonder?
00:35 bshum Well, there's some new stuff in Evergreen to map formats and item materials.
00:35 dcook Are you at home, bshum? Why are you up so late?
00:36 bshum I wonder if we use any of that towards adopting 3xx tag data
00:36 bshum To define what a thing is
00:36 dcook Might be an idea
00:36 bshum dcook: I'm up at all sorts of weird hours.
00:37 bshum Someday I'll sleep more :)
00:37 bshum Or have a life.
00:41 bshum dcook: It's been awhile but Koha has a sample dataset that you can load on install for demo, right? Do you guys toy with MARC nonsense there too?
00:49 * bshum may find out later tomorrow.
00:49 bshum For now, attempts to sleep.
01:00 dcook Hmm, good question
01:00 dcook Off the top of my head, I don't think there is a sample dataset.
01:00 dcook Actually, I would say I'm 90% certain there is no sample MARC dataset with any install of Koha.
01:01 dcook Since we support MARC21, UNIMARC, and NORMARC...we toy with all the MARC nonsense ;)
01:01 dcook We have a couple ways of displaying records...my favourite being via XSLT.
01:02 dcook It makes showing multiple 264s a breeze. At the moment, I don't think we differentiate between the different types of 264, but it would be a trivial change to make.
01:02 dcook In any case, sleep well!
01:57 zerick joined #evergreen
05:13 pinesol_green Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html>
07:38 akilsdonk joined #evergreen
08:05 Dyrcona joined #evergreen
08:07 Dyrcona So, I get daily promotional emails from Packt Publishing because I've bought some ebooks directly from them in the past.
08:08 Dyrcona Today's promotion is "Save 50% on JavaScript titles."
08:08 Dyrcona Their lead title is Learning Dart.
08:08 Dyrcona :)
08:09 Dyrcona Just thought that was amusing.
08:13 mmorgan joined #evergreen
08:19 b_bonner joined #evergreen
08:20 BigRig joined #evergreen
08:22 mrpeters joined #evergreen
08:26 Shae joined #evergreen
08:29 rjackson-isl joined #evergreen
08:33 * Dyrcona flips Launchpad the bird.
08:37 timf joined #evergreen
08:42 bshum Hmm, thoughts on this... I see two more new questions in the LP tracker area for questions, from 4/7 and 4/8
08:43 bshum I'm tempted to email the general list to recommend people do not use this part of LP to ask questions, but to email the lists, etc.
08:43 bshum It's not something we're actively watching as a community (as far as I know)
08:44 bshum https://answers.launchpad.net/evergreen
08:44 ericar joined #evergreen
08:44 * bshum wonders how this became popular again
08:48 Dyrcona bshum: If its there, someone will use it.
08:48 bshum I suppose that's true.
08:48 dbs bshum: to follow up on your convo with dcook, no, koha doesn't have a sample set of RDA records; I always load sample records from Evergreen's test datasets into Koha :)
08:49 bshum Dyrcona: Maybe we need something in Questions on LP like what jcamins did for our issues tracker in github:  https://github.com/evergreen-li​brary-system/Evergreen/issues/9
08:49 bshum But to subtly point people at the lists
08:49 dbs The "trawl LoC for sample RDA records" approach could work, although it's not as though LoC hasn't made errors before.
08:49 Dyrcona bshum: Subtly doesn't work. You need a very big hammer.
08:50 bshum Dyrcona: I think the part that bothers me most is that nobody gets notified by LP when new questions are lodged
08:50 dbs Which is why it's so freaking frustrating that all of these standards-creators haven't simply created a set of records that they can agree represents best practices!
08:50 Dyrcona dbs: I can throw some records with some of the 264 data at you.
08:50 Dyrcona OCLC be damned. :p
08:51 dbs Some is better than none.
08:51 Dyrcona I'll see if I can dig up the IDs of the two or three that I used for testing.
08:52 * dbs also hopes, like bshum, that the 3xx were taken into account with all the MVF/CRA stuff
08:53 * dbs peers with interest at http://www.loc.gov/standards​/mods/mods-conversions.html - nope, still no MARCtoMODS3.5 XSLT
08:54 dbs Although there is an RDAtoMODS3.4 XSL (as in, Excel spreadsheet; and it's horrible)
08:54 kbeswick joined #evergreen
08:55 dbs Example mapping from RDA to MODS 3.4 entry: "Item-specific carrier characteristics of early printed resources" to "physicalDescription/note"
08:57 dbs joined #evergreen
09:00 dbs s/XSL/XLS/ # phew, feel better now.
09:01 jeff heh
09:01 bshum Dyrcona: Sigh, now that I'm looking I can see how people could end up down the rabbit hole with questions.  Not like there aren't enough "ask a question" links in LP.
09:01 bshum @hate launchpad
09:01 pinesol_green bshum: But bshum already hates launchpad!
09:02 Dyrcona @hates
09:02 pinesol_green Dyrcona hates parts; MARC; vacation; their/there; English orthography; Launchpad; RDA; typos; Launchpad Search; printing; and NCIP
09:02 Dyrcona @hate Launchpad_some_moar
09:02 pinesol_green Dyrcona: The operation succeeded.  Dyrcona hates Launchpad_some_moar.
09:02 Dyrcona And if we hate it, why do we use it?
09:03 bshum Dyrcona: It's because you didn't come to the lunch dev meeting at the conference to help remind me why I hate it so much.
09:03 bshum Okay, so we can setup notifications for questions in LP
09:03 bshum Right now there are no "answer contacts" which is why nobody is notified
09:04 bshum But do we even want to use it
09:04 bshum Sigh
09:04 Dyrcona @eightball
09:04 pinesol_green Dyrcona: No clue.
09:04 Dyrcona Well, that doesn't help. :)
09:05 mmorgan bshum: Do we have a choice but to use it? Can it even be disabled?
09:05 bshum mmorgan: No, we don't have a choice to disable it.  But we could actively discourage it by putting up signs and otherwise continue ignoring it :)
09:06 bshum But meh
09:06 mmorgan Can the answer contact be set as the general list?
09:06 dbs We use Launchpad because it does almost everything we want. And more! It's mostly the "And more!" that causes problems though.
09:06 Dyrcona So, looks like I have 18 098 records with at least 1 264 tag. Guess that is too many. :)
09:07 dbs Dyrcona: can you find some that have a 264, some 3xx, and some RDA 7xx?
09:08 bshum mmorgan: No, it looks like I can subscribe myself personally, or add different teams (like bug wranglers) as contact groups.
09:08 bshum I'm hesitant to just add the bug wranglers to auto subscribe to this area without at least some more discussion by the project.
09:09 bshum And I would add myself, but I'm also reluctant to commit to answering questions in that forum.
09:09 bshum :D
09:13 Dyrcona bshum: I would not add any teams.
09:14 * dbs closes eyes and covers ears to unsee the RDA 7xx recommendations to use $e with literal values instead of $4 relator codes
09:15 dbs Because, you know, $e is so multilingual and linkable
09:15 Dyrcona Hmmm.. I either got my like syntax wrong or we only have 1 record with either a 3xx or 7xxx that doesn't have a 264.
09:16 jcamins dbs: it's Linked Data!
09:16 dbs Dyrcona: that's a good sign
09:17 jcamins I went to a talk where a person from the RDA taskforce informed an audience of catalogers very seriously that RDA was designed the way it was because computer scientists insisted on it being like that.
09:17 jcamins And that this new format was "Linked Data."
09:17 dbs jcamins: are you sure that person didn't say "mad scientologist"?
09:18 jcamins dbs: quite sure. That's why it stuck in my memory.
09:20 * Dyrcona has a very low opinion of "computer science."
09:20 dbs jcamins: how did that feel to be in the audience?
09:20 Dyrcona And it in no way belongs in the same college as Engineering, but that's where it usually ends up.
09:23 dbs Dyrcona: if you have any records with a 7xx $i, that could be interesting
09:24 Dyrcona dbs: I'll see. Right now, I'm getting a count of records with 264, 3xx, and 7xx.
09:24 dbs Dyrcona++
09:25 Dyrcona I'll add a subfield i on the 7xx and see if that gets me less than 6 633.
09:25 * dbs predicts 0 :)
09:26 Dyrcona 517!
09:26 dbs Hey, nice!
09:26 Dyrcona Well, just 517 and no the mathematical 517!.
09:26 dbs Grab 1/10 of those for a sample set?
09:27 Dyrcona will do.
09:31 alynn26 joined #evergreen
10:09 atlas__ joined #evergreen
10:10 Dyrcona dbs: I put another file up without all of the electornic records in it.
10:10 Dyrcona It looks about 1 : 50 of our database records are RDA compatible or whatever.
10:13 Dyrcona Heh. The first two records in my new sample are perfect for the Concerto dataset: Dvorak violin concertos, and a death metal CD by Amon Amarth.
10:14 denishpatel joined #evergreen
10:19 dluch joined #evergreen
10:25 dbs oh yay
10:26 dbs Dyrcona++
10:38 ldwhalen joined #evergreen
10:57 csharp is anyone aside from KCLS using the PayPal/PayFlowPro additions?  I've been asked to look into that for PINES...
10:59 bshum csharp: I vaguely feel like C/W MARS implemented Paypal?
11:01 bshum Or maybe they were just looking too
11:02 Dyrcona I can say that we haven't because of municipal regulations and fees/fines and fees for processing, etc., and all but 1 of our members is a public entity.
11:04 Dyrcona Can't pay with a credit card either for the same reasons.
11:46 * mmorgan is puzzled about entries in the osrfsys log for checkins.
11:47 mmorgan grep do_checkin osrfsys.09.log
11:47 mmorgan I see many barcodes that have multiple entries a few hundredths of a second apart.
11:47 mmorgan 2014-03-26 09:47:16 app201 open-ils.circ: [INFO:29949:Circulate.pm:3613:13958414252941622] circulator: do_checkin() requestor=346, recipient=2022702, copy=31760004337848
11:47 mmorgan 2014-03-26 09:47:20 app201 open-ils.circ: [INFO:29949:Circulate.pm:3613:13958415743044710] circulator: do_checkin() requestor=346, recipient=2022702, copy=31760004337848
11:48 mmorgan I see this for a lot of checkins in any give hour
11:48 mmorgan Is this normal? Seems odd to me.
11:48 mmorgan s/give/given
11:51 Christineb joined #evergreen
11:54 csharp mmorgan: you can grep the threadtrace to see all the logs for a given action (e.g., 'grep 13958414252941622 osrfsys.09.log | less')
11:54 csharp mmorgan: that assumes that you chop your logs up by date/hour like we do
11:56 mmorgan csharp: Thanks, that's helpful. Yes we do chop them up by hour.
11:57 csharp mmorgan: you can also search the threadtrace in the activity.log (assuming that's there too)
11:59 Dyrcona mmorgan: Circulation code is a mess, I see things going through it 3 and four times, even when testing and I know I only checked it in once.
12:00 Dyrcona mmorgan: There's a) too much logging and b) too much bouncing back and forth among different methods.
12:00 mmorgan yes, activity is there, too. I get a single line from activity for one of these threadtraces, and a whole bunch of stuff going on with the other one.
12:01 mmorgan I know we have had a few situations where the same item was captured by two different holds. That's what brought me to this.
12:03 mmorgan Dyrcona: that does not fill me with confidence :-(
12:05 mmorgan I was thinking items were being double scanned, but this looks to be too many.
12:11 jihpringle joined #evergreen
12:12 mmorgan ok, interesting. For the 2 threadtraces for each related checkin log entry, activity.log shows "open-ils.circ.checkin" for one and "open-ils.circ.checkin.override" for the other.
12:13 mmorgan so maybe this isn't as odd as it first looks.
12:14 Dyrcona mmorgan: That's not so odd. IIRC, the .override will be called if there is something to override about a checkin.
12:14 Dyrcona Circ is still a mess. :)
12:15 mmorgan ok, I'll give you that :)
12:16 * mmorgan is going to stop trying to completely understand evergreen logs. At least until after lunch.
12:17 mmorgan csharp++
12:17 mmorgan Dyrcona++
12:31 Bmagic anyone develop simple jquery on the opac?
12:32 bmills joined #evergreen
12:32 Bmagic I'm having an issue that looks like the dojo JS script runs and horks the DOM which makes my jquery break
12:34 Bmagic firefox console tells me: undefineddojo._scopeArgs = [undefined];
12:36 jboyer-isl Today's lesson: if you're going to use a shell script for a nagios check, maybe mark it executable?
12:43 tsbere jboyer-isl: But what if the check is "does the OS refuse to execute shell scripts not set to execute?" ;) (and yes, I have run into a linux box that stopped caring about the execute flag once, though I never did find out why)
12:43 jboyer-isl That bug sounds exciting.
12:56 timf joined #evergreen
12:59 hbrennan joined #evergreen
13:03 fparks joined #evergreen
13:27 eeevil dbwells: just a head's up, if gmcharlt's fixed field seed data ends up getting into 2.6.0, that needs to come /before/ the MVF/CRA conversion dance, so that the existing values are seen as controlled instead of uncontrolled
13:39 * csharp really dislikes "does program X work with Evergreen?" questions
13:39 csharp my pat answer is "test it and see"
13:42 tsbere csharp: My first desire is to turn around and say "Does it have any reason to interact with the ILS directly?"  For example, "Does Office work with Evergreen?" Well, since it doesn't actually interact with Evergreen at all to begin with....
13:47 _bott_ Reporter creates .xls files, so yes.  In a 7 degrees of Kevin Bacon kinda way.
13:48 jeff i need to work on guidelines for transitioning some willing initial staff members from "one account for all" to "this is my patron account" and "this is my staff member account"
13:48 bibliophylum joined #evergreen
13:51 csharp tsbere: this particular question is more about extending the OPAC with vendor widgets
13:51 tsbere csharp: Ahhh. That can be more complicated and/or annoying. <_<
13:51 csharp usually both in my experience ;-)
13:52 csharp and I'm usually dealing with it after a library has purchased said service on the breezy assurances of the vendors
13:52 csharp rather than after a rigorous test, which I'm happy to coordinate on our end ;-)
13:53 csharp at least this particular library asked ahead of time, so I should be happy, not complaining
13:53 * csharp is just tired today
13:54 csharp jeff: are you doing that in a software-based way, or from a "this is my staff card, but *this* is my patron card" way?
13:55 _bott_ jeff:  we chose to transition unwilling staff into "this is your only account and you'll like it"
13:58 * tsbere would like to move to *either* of those setups at MVLC, but can't
13:59 bibliophylum Hey folks... I'm trying to explain to non-technical bosses what the implications of Heartbleed on Evergreen systems are.  I've already covered, "we're aware of this *because* it's open source" and "no, there's no way of telling if a system was targeted", and "yes, it's patched".  Any thoughts/tips?
14:00 tsbere bibliophylum: Show them today's XKCD and explain that the attacker can't actually control what was returned anyway?
14:00 bibliophylum tsbere: heh - already did :-)
14:02 jboyer-isl bibliophylum: potential patron session key retrieval, which could lead to bad actors posing as patrons to compromise privacy or just place holds on books they wouldn't like. Limited by the lifetime of the key in cache and the ability of the attacker to already know enough about evergreen to have most of that planned out.
14:03 csharp bibliophylum: I thought this was a nice summary - not too technical, but not dumbing down either: http://www.newyorker.com/online/blogs/elements/​2014/04/the-internets-telltale-heartbleed.html
14:03 jboyer-isl That's just what comes to mind, not the full extent of the problem.
14:03 csharp "But, before you panic, it is worth remembering that, at this point, we don’t know how close we are to the worst-case scenario. It is possible, though improbable, that the security researchers who exposed this flaw were, in fact, the first people to find it, which would mean that it has only been known about, and exploited, for a few days."
14:04 bibliophylum Ah, excellent!
14:04 bibliophylum Thanks, tsbere, jboyer-isl, and csharp :-)
14:10 ldwhalen joined #evergreen
14:11 kbutler joined #evergreen
14:17 gmcharlt eeevil: as far as foks tracking master a concerned, am I on target that selective use of  metabib.reingest_record_attributes will fix up mravl after new ccvm rows are added?
14:18 eeevil gmcharlt: yes. there will be orphaned rows in the uncontrolled table, but only as many as were added to the ccvm table.
14:19 gmcharlt orphaned rows in that table don't strike me as a big deal -- correct?
14:19 eeevil correct
14:20 eeevil eventually we'll want a mechanism for removing them, but it's no worse (and likely much less "bad") than the bloat that will accumulate in metabib.browse_entry
14:22 gmcharlt the UK on (attr, value) is going to put a strict limit on how far even the most ambitious of fixed fields can bloat that table
14:45 tsbere eeevil / gmcharlt: Could this help? http://pastebin.com/GFtbyPJy
14:46 gmcharlt tsbere: on the face of it, looks much nicer than an attribute reingest
14:49 eeevil agreed. purty
14:49 gmcharlt tsbere++
14:50 * tsbere almost finds the WITH block abuse scary, though
14:53 tsbere eeevil / gmcharlt: I very lightly tested it. Was thinking it might be best set up as a cron job, but not sure.
14:53 jeff for evergreen specific impacts, if your ssl-speaking front-ends were apache linked against a vulnerable version of openssl, it was trivial to steal recently used session keys as well as cleartext credentials for recent logins. (or not-so-recent in terms of "wall clock time" if the target system was idle).
14:54 * eeevil grumbles about CHAP ... ;)
14:54 * Dyrcona just read some articles saying that exploits may have been circulating as long as last November.
14:55 jeff if your front end was pound or nginx linked against a vulnerable version of openssl, i make no assertions because i didn't test that. :-)
14:55 jeff we were happily on squeeze for ssl-speaking production systems. :-)
14:57 Dyrcona 'Ow nice for you.
15:24 ldwhalen joined #evergreen
15:54 jboyer-isl Does anyone else have any issues with Clark processes piling up around midnight (when most "I don't care when" reports are run)? Ours can creep up to 40+ processes a night, triggering an icinga alert almost daily. (we only run with -c 5, so that's over 8x the expected number of processes)
15:59 timhome joined #evergreen
16:01 alynn26 left #evergreen
16:09 bmills Hello, I was wondering if the library setting "Patron Login Timeout" (for the selfcheck) is functional? The documentation says that it is not currently supported, and we have a few libraries that are reporting longer timeouts than expected.
16:17 jeff bmills: can you point me to where in the documentation you're seeing that?
16:18 jeff bmills: and do you know if you're using the current or the old/legacy self checkout interface? i'm assuming you're talking about evergreen's web based self checkout functionality?
16:18 jeff bmills: and perhaps last... what is happening, and what do you expect to happen instead?
16:26 Bmagic Can Dojo 1.3.3 traverse the dom?
16:27 bmills jeff: i'm looking at http://docs.evergreen-ils.o​rg/2.5/_self_checkout.html, we are using the new web-based self checkout and we have just been getting reports from libraries that the patron's account is left up on the screen if they forget to log out, and hasn't been timing out at the set library settings. thanks!
16:27 ldwhalen joined #evergreen
16:31 jihpringle bmills: we have one library using the self check on 2.4 and we found that the timeout just didn't work
16:31 jeff bmills: the documentation appears to be correct. the older legacy self checkout interface made use of that timeout, and the new interface does not currently. worth a bug, if there's no bug filed yet.
16:34 hbrennan I would be happy to tag onto the LP bug report, even though we don't currently use self-checkin. The security problems with that alone would be enough to prevent us from implementing it.
16:36 jihpringle we fixed this for our library but haven't  had a chance to push the fix upstream yet, if someone creates a bug let me know and I'll add the bug number to our internal ticket
16:36 bmills ok, thank you. i'll let the libraries know
16:37 bmills jihpringle++ jeff++
16:37 bmills i think that was correct…
16:41 dbs Bmagic: what kind of DOM traversal are you looking for?
16:42 Bmagic Im trying to start simple, like foreach element print an attribute
16:43 jeff Bmagic: what's your larger goal?
16:44 Bmagic We would like to increase any font-size css by *1.5
16:45 dbs And the larger goal for that?
16:45 jeff Bmagic: but to answer your question, have you tried dojo.query() combined with dojo.forEach() ?
16:45 Bmagic I have but I must be using it wrong
16:46 Bmagic If you tell me that 1.3.3 will work without the documented dojo.require("dojo.NodeList-traverse"); statement then I will continue
16:48 Bmagic dojo.forEach(obje,function(node){nod​e.children().forEach(function(node){       Look right to you?
16:48 dbs the CSS3 queries can be tricky. and there's still some browser specificity (hi IE)
16:49 * dbs squints. been a long time, but I would have expected something like dojo.query().forEach()
16:49 Bmagic yes... I left out that part:  dojo.query("body").forEach(function(node){
16:50 * dbs has to ask if this is something that could just be handled via TPAC CSS instead, assuming TPAC
16:50 jcamins Bmagic: I know nothing about the CSS used by Evergreen, but you did try increasing the font-size on the body and confirming that this didn't increase the size of everything, right?
16:51 Bmagic dbs: Our inital thought was css of course but we started thinking that if we change the css for other templates, we would need to integrate those changes to this template everytime
16:51 Bmagic Instead, if we had a JS traverse to do it for those that want it, we can maintain a single css instance
16:52 Bmagic I started this project with jquery in mind this morning and quickly found out that dojo screws up the DOM for jquery
16:53 jeff this is also possible: dojo.query('a').addClass('red')
16:53 dbs jcamins is right, most of our font sizes are relative to body
16:53 jeff but of course, appending a class if it's not already present leaves you at the mercy of css specificity.
16:54 dbs Open-ILS/src/templates/opac/parts/css/fonts.tt2 doesn't look horrible to integrate changes into...
16:54 dbs Again, I'm missing all kinds of context though :)
16:54 * dbs just avoids JS if at all possible these days
16:54 bshum swivels!
16:54 jcamins If you want to use javascript but the change can be done with the simple CSS, you could always do body.styles.fontSize = whatever.
16:55 jeff likewise. hopefully we've given you a healthy mix of "answering your question" and "cautioning against the approach you're considering" :-)
16:55 Bmagic :) thanks - I didnt want to do it either but now that I am in the thick of it, I want to see it work
16:55 jcamins (where body is a placeholder for the element, and styles might be called style)
16:55 jcamins dbs: BTW, Laurentian's catalog looks fine without JS.
16:55 jeff bshum: "swivels!" -- talk about missing some context. hopefully you didn't have a terrible run-in with an AMH/sorter? :-)
16:56 * jcamins just tested it to see if TPAC handled no-JS pleasantly.
16:57 pinesol_green Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html>
16:57 bshum jeff: I was just remarking where dbs mentioned avoiding JS as much as possible and how berick and senator at the hackaway two years ago had thoughts about more swivels with JS to smooth out the transitions in record summary
16:57 bshum For the added content, etc.
16:57 Dyrcona jcamins: That was kind of the point of TPAC, no JS.
16:57 jcamins Dyrcona: I know, but that doesn't mean it _worked_. I was pleased to find that it did.
16:58 bshum jeff: But no, I managed to avoid harm with the AMH yesterday.
16:58 jeff good to hear :-)
16:59 bshum The thing I have to look more closely for them is apparently to do with timing.  Our SIP response rate for the checkins is too wildly variable for their liking.
16:59 bshum Like, oh this went through at 600ms, cool.  The next thing is 1300 ms and apparently that's "too long".
16:59 jeff they're sensitive to varied response time, not just exceeding a max timeout?
16:59 bshum Mostly just worried about exceeding the time
16:59 jeff ah
17:00 jeff because the other seemed odd.
17:00 dbs jcamins: we've worked hard to make the catalog work with JS... the Laurentian catalogue is a few versions behind
17:00 bshum They were scratching their heads about the variability though.  As far as being unpredictable.
17:00 dbs with _without_ JS. duh
17:00 bshum Such is life.
17:01 jeff i'm all for increasing transaction speed, but did they not understand that it might take a longer amount of time to check in some items than others, with regard to hold capture, etc? ;-)
17:01 bshum Yeah their tech didn't quite believe that answer when I tried to explain it.
17:01 bshum :)
17:02 bshum But holds will probably need more special care anyways.
17:02 bshum This library will be the first in our consortium to go RFID and sorter.  Their stuff will be the only things with tags on them.  ILLs won't be tagged, so they're all going to exceptions anyways.
17:02 dbs > 1 second is pretty long in the world of the web
17:02 bshum It'll be an interesting prospect.
17:03 bshum dbs: Indeed, true.
17:05 jeff i kinda' want to add timelog-like bits to circ, similar to what was added to tpac. obviously it wouldn't be displayed in a browser, and maybe some/all of the bits are there and i'm just not parsing the logs (by hand or in an automated way) well enough...
17:16 bmills submitted a bug report for the patron timeout setting in the new self check: https://bugs.launchpad.net/evergreen/+bug/1306814
17:16 pinesol_green Launchpad bug 1306814 in Evergreen "Self checkout ignoring patron timeout library setting" (affected: 1, heat: 6) [Undecided,New]
17:16 gmcharlt dbwells: you may find this darkly amusing
17:16 gmcharlt er, rather, dbs: http://paste.lisp.org/display/142004
17:17 gmcharlt a good ISBN to try it with is 9264023607
17:19 hbrennan bmills++
17:25 jeff gmcharlt: wow.
17:25 jeff also, ow.
17:27 gmcharlt jeff: I know -- and somehow, it doesn't seem quite polite to try three different API calls to OL per title to try to find, for a given identifier, the edition that has a cover associated with it
17:28 jeff i've been considering same for syndetics, though...
17:28 jeff cover/jacket images at all costs!
17:28 jeff xkcd 416
17:28 jeff http://xkcd.com/416/ Zealous Autoconfig
17:29 gmcharlt ha!
17:29 mmorgan left #evergreen
17:41 ldwhalen joined #evergreen
17:41 atlas__ joined #evergreen
17:48 hbrennan_at_lunc It's possible I may be hungry
17:51 gmcharlt hbrennan_at_lunc: enjoy testing that hypothesis empirically!
18:27 dbs gmcharlt: I believe it's possible to issue multiple requests per Read API request; travelling back in time to when I was talking with the OpenLibrary folk about their rate-limiting etc
18:28 dbs I brought up the exact same point: "So, you're not rate limiting the Read API, but I end up making _more_ requests than via the Cover API?" They agreed that was silly.
18:28 gmcharlt dbs: I've verified that is is; possibly something for mark 2 of my patch for bug 1306258
18:28 pinesol_green Launchpad bug 1306258 in Evergreen "more seed data for MARC21 fixed field values would be nice" (affected: 1, heat: 6) [Wishlist,New] https://launchpad.net/bugs/1306258
18:29 dbs https://blog.openlibrary.org/201​1/04/27/coverstore-improvements/
18:29 dbs Oh I have no doubt
18:29 bmills left #evergreen
18:29 dbs but https://github.com/interneta​rchive/openlibrary/issues/15 fwiw
18:30 gmcharlt ah, and https://github.com/internetarchive/openlibrary/​commit/14adbafda615b754fcdd3b503a626820856dee75
18:30 dbs yes
18:30 dbs So historically they were receptive, but of course things get lost over the span of 3 years and staff turnover
18:32 gmcharlt in that case, simplest approach would seem to be direct use of the covers API, since at least for my example, it recognizes both the ISBN13 and ISBN10 without muss and fuss
18:32 dbs gmcharlt: but that means giving up on tables of contents and... something else
18:32 gmcharlt I do get the impression from the ol-tech archives that the past couple years has been rough for them
18:33 gmcharlt also, it doesn't necessary mean giving up TOCs and the like -- just usnig the Read API for the former and the covers API for the covers
18:33 dbs Oh, I see
18:33 gmcharlt which yeah, would bump up the number of requests somewhat, but that's why we cache
18:33 dbs Yes, they're barely in maintenance mode
18:33 dbs Well, you're clearly on the warpath, so have at it
18:34 gmcharlt yeah, I'm working with somebody who wants to eke out every last cover image they can
18:34 gmcharlt do you have a notion of who I should talk to to get my ol-tech post out of moderation?
18:35 dbs I guess the idea though was that the Read API would give you the added content plus links to any covers, if they exist, so it's still not clear to me why we would do two separate calls
18:35 dbs gmcharlt: jessamyn?
18:35 gmcharlt ok
18:36 gmcharlt oh, and the reason why? inconsistencies like feeding "isbn:9264023607" to the Read API and /not/ get back an edition record that contains links to the covers
18:36 gmcharlt even though using that same ISBN for the Covers API directly... works
18:37 dbs Sounds like an upstream issue really
18:37 gmcharlt IOW, lp1306258 is all abound working around rough edges in OL's data store and/or API implementations :/
18:38 dbs pull requests accepted at https://github.com/internetarchive/openlibrary apparently
18:38 * dbs gets ready to submit a pull request for "Code Oraganization" typo in the README
18:38 bshum gmcharlt: Am I misreading the bug numbers or did you just link to the wrong bug?
18:38 bshum link/type to
18:39 bshum seed data vs. openlibrary
18:39 dbs Alternately, could just grab the cover dump and have a really big local cache
18:39 dbs bshum: correctamundo bug 1306823
18:39 pinesol_green Launchpad bug 1306823 in Evergreen "available covers not being retrieved from OpenLibrary for some titles" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1306823
18:40 gmcharlt and yeah, it /ought/ to be an upstream issue, but glancing at the open vs. closed pullrequest suggests I'd be in for a long wait for anything that isn't a doc fix
18:41 bshum dbs: Aha
18:44 dbs most of the 9 pullrequests are typo fixes, I could understand a lack of interest in those
18:45 gmcharlt dbs: I thnk there probably is space for a new community cover image service, though I'd rather see a way for OL to be funded more stably as a service, not just something that seems to be done just on the back of one techie at the IA and some volunteer time, as laudable as their efforts have been
18:45 * dbs sees gmcharlt's comment on https://github.com/interneta​rchive/openlibrary/issues/27 - guess you've been at this for a while :)
18:46 gmcharlt dbs: eventually I'll catch up with you in this area ;)
18:46 dbs Sure, I think the challenge is having someone willing to back such a service. Brewster isn't going to fold at the first sign of a copyright challenge; hard to find others with that stance
18:47 dbs gmcharlt: oh heck, I think you're already well past me
18:48 gmcharlt yeah, I'd imagine that's where most of the expense would be, not the technology (particularly if a service were limited to /just/ proviing cover images and dipped its toes in bib metadata issues as little as possible)
19:19 mcooper joined #evergreen
19:29 ldwhalen joined #evergreen
19:34 mrpeters left #evergreen
20:26 ldwhalen joined #evergreen
20:31 ldwhalen_mobile joined #evergreen
21:01 dave_bn joined #evergreen
21:05 dave_bn hi everybody
21:05 dave_bn I have a difficult question.  Can I specify somewhere in TPAC that certain branch be preselected as search location when OPAC is loaded?
21:07 dave_bn Something like this: http://domain.com/eg/opac/home?locg=14; would preselect branch ID 14
21:08 dave_bn bu is there a way to go to http://domain.com/eg/opac/home and already see branch ID 14 preselected as search scope?
21:12 dave_bn or perheps specify default branch somewhere, so it is selected whenever I visit opac
21:16 jihpringle dave_bn: I don't know the answer to your question, but I recommend that you ask it on the general list serv or come back and ask it during regular business hours Eastern time when the channel is much busier
21:19 dave_bn jihpringle: Thanks for the info. I will come back during business hours then :)
21:19 jihpringle np
21:46 bshum @later tell dave_bn One way to accomplish what you're asking for is to make use of the "physical_loc" apache variable in various virtualhosts. We do this in our system so that library1.org directs to physical_loc=1, library2.org directs to physical_loc=2, etc. for scoping purposes.
21:46 pinesol_green bshum: The operation succeeded.
21:50 bshum @later tell dave_bn See the snippet from http://en.flossmanuals.net/evergreen-in-action/​enabling-users-to-find-what-theyre-looking-for/ that describes the "physical_loc" variable.
21:50 pinesol_green bshum: The operation succeeded.
21:51 bshum Which unrelated is a very badly named URL because it's really about designing the catalog and customizing TPAC.
21:51 bshum Well, not "very badly" I guess....
21:52 * bshum wanders back to his nap
23:01 jeff heh. i didn't expect it to take TOO long for the "list list is not to be published to the web" line to be violated. :-)
23:23 bshum Alas.

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat