2010-04-01T00:14:41 *** mck9 has left #evergreen 2010-04-01T02:01:50 *** pmplett has quit IRC 2010-04-01T02:23:30 *** gmcharlt has quit IRC 2010-04-01T02:23:43 *** gmcharlt has joined #evergreen 2010-04-01T03:16:47 *** gdunbar has quit IRC 2010-04-01T07:01:26 *** gmcharlt has quit IRC 2010-04-01T07:01:26 *** gmcharlt has joined #evergreen 2010-04-01T08:06:27 *** mck9 has joined #evergreen 2010-04-01T08:07:24 *** atheos_ has joined #evergreen 2010-04-01T08:13:24 morning evergreeners, I'm troubleshooting a problem with SIP. We just installed new SIP based self check units, and discovered that items with diacritics in the titles wouldn't scan. I assumed it was the self check, sentry says it's on the evergreen side. So, to test, I'm manually communicating with SIP sending the Item Information command (17). I get a standard ACS response on all items as I would 2010-04-01T08:14:02 the SIP connection just hangs in this case, until you manually break the SIP connection from the client side and restart. 2010-04-01T08:20:21 *** collum has joined #evergreen 2010-04-01T08:33:41 *** Melissa has joined #evergreen 2010-04-01T09:03:06 atheos_: dbs has dealt with diacritics and 3M self-check sometime in the last year or so... you might check logs or the list, or pester him when he comes online. 2010-04-01T09:08:07 thanks jeff, I think I found the issue in Item.pm At some point, someone edited the file and removed $t =~ s/\pM+//og; not sure what they were trying to fix, but I believe it's the root of my problem 2010-04-01T09:08:58 *** atheos_ has quit IRC 2010-04-01T09:09:40 *** jenny has joined #evergreen 2010-04-01T09:15:25 *** bshum has joined #evergreen 2010-04-01T09:17:31 *** Melissa has quit IRC 2010-04-01T09:17:58 *** Melissa has joined #evergreen 2010-04-01T09:25:48 *** gdunbar has joined #evergreen 2010-04-01T09:35:43 *** sfortin has joined #evergreen 2010-04-01T09:57:34 *** grantjohnson has joined #evergreen 2010-04-01T09:57:43 *** dbs has joined #evergreen 2010-04-01T10:15:50 *** brendan_bywater has joined #evergreen 2010-04-01T10:33:33 *** Melissa has quit IRC 2010-04-01T10:35:26 *** brendan_bywater has quit IRC 2010-04-01T10:48:30 *** Melissa has joined #evergreen 2010-04-01T10:59:44 *** neraath has joined #evergreen 2010-04-01T10:59:51 Howdy everyone! 2010-04-01T11:01:27 *** StephenGWills has joined #evergreen 2010-04-01T11:03:45 I posted in here last night about some problems I was having with the autogen.sh script. Anyone in here have a chance to take a look at it, or should I re-post what problems I was having? 2010-04-01T11:05:22 this is definitely a problem: "The only thing is it takes about 13-14 seconds for the settings server to respond - which explains why Updating fieldmapper times out." but I don't know what is causing it 2010-04-01T11:05:46 I think folks were musing DNS 2010-04-01T11:05:46 And unfortunately I have no idea what's causing it either, heh 2010-04-01T11:06:13 Well, regarding DNS, does the server actually poll for other things besides its hostname? 2010-04-01T11:06:21 Database is local. 2010-04-01T11:06:55 And all possible entries it'd be using (fqdn, localhost, private.localhost, public.localhost, etc.) are all defined in /etc/hosts 2010-04-01T11:08:41 fwiw, I'm trying this on Gentoo AMD64 virtual machine. 2010-04-01T11:09:00 phasefx pasted "/etc/nsswitch.conf" at http://paste.lisp.org/display/97199 2010-04-01T11:09:13 does your nsswitch.conf differ from that? 2010-04-01T11:09:29 yes. I use LDAP authentication 2010-04-01T11:09:55 however, are you specifically referring to the hosts section? 2010-04-01T11:10:09 this is all vague voodoo to me, just digging 2010-04-01T11:10:55 neraath pasted "nsswitch.conf - LDAP auth" at http://paste.lisp.org/display/97200 2010-04-01T11:11:00 is the request in srfsh consistently 13-14 seconds? 2010-04-01T11:12:38 It had been pretty consistent yesterday afternoon. 2010-04-01T11:12:45 I'm restarting all services to try again now. 2010-04-01T11:13:04 all processes became defunct upon shutdown (*sighs*) so it's gonna take me a couple of minutes. 2010-04-01T11:13:33 if it's just that one call, and other services and methods seem to work quickly, you can increase the timeout in the perl script that autogen calls 2010-04-01T11:13:34 heh - load is now 62.33, 19.24, 6.73 2010-04-01T11:13:48 it may be related to xml libs 2010-04-01T11:13:51 well that's what I was looking for - I don't see a place for timeout in autogen.sh 2010-04-01T11:16:02 now, y'all wouldn't know if certain kernel security measures (grsec) would be causing problems? 2010-04-01T11:16:09 that's the only other thing I can think of 2010-04-01T11:18:25 does this produce output instantly? perl /openils/bin/fieldmapper.pl /openils/conf/opensrf_core.xml 2010-04-01T11:20:14 take a look at http://evergreen-ils.org/irc_logs/evergreen/2009-11/%23evergreen.19-Thu-2009.log starting around 2009-11-19T10:03:14 2010-04-01T11:20:58 *** Melissa has left #evergreen 2010-04-01T11:22:22 *** Meliss has joined #evergreen 2010-04-01T11:27:25 neraath: so following that IRC conversation, I don't see any real resolution but mrpeters-isl had the same problem, and ultimately modified SettingsClient.pm to increase the timeouts. I don't think that'd be suitable for a production instance though 2010-04-01T11:32:16 yea, I've been reading through it and it definitely seems like the exact same problem 2010-04-01T11:32:24 (I'm surprised google didn't find it for me, heh0 2010-04-01T11:32:38 Well, at this point I'm just evaluating the software. 2010-04-01T11:32:55 We've been looking for something that would handle equipment reservations for our media center 2010-04-01T11:33:17 I've searched high and low and there are 0 worthwhile open source products out there as far as I can find 2010-04-01T11:33:28 phpLabMan is no longer maintained 2010-04-01T11:33:56 MERCI for Drupal is poorly maintained and doesn't even have a way to associate a user with an equipment reservation. 2010-04-01T11:34:27 *** r123 has joined #evergreen 2010-04-01T11:34:35 So yea, library reservations/management was about 15th on the list of things to try, and it's the first that seems to have any sort of viable solution (that being Evergreen) 2010-04-01T11:36:34 neraath: I know that others have had to disable selinux extentions, so grsec could be a problem ... disabling that is worth a shot for troubleshooting purposes 2010-04-01T11:37:03 okay. I'll try that out and see if I get any improvement. 2010-04-01T11:46:51 *** jenny has quit IRC 2010-04-01T11:53:11 kernel recompiling done. Rebooting the system with the new kernel. 2010-04-01T12:03:16 * dbs crosses fingers for neraath 2010-04-01T12:03:33 that said, evergreen might be overkill for an equipment reservation system... 2010-04-01T12:06:06 well, I got that feeling about 1/3 of the way through the install, heh 2010-04-01T12:06:19 But, like I said, it seems to be the only thing that actually is sustainable as something already pre-built. 2010-04-01T12:06:58 I'd probably whip something together in Ruby/Rails in 2 weeks time that could pseudo-serve as a equipment reservation system, but I'm 100% tapped out on software development time for other projects....so yea. 2010-04-01T12:07:12 Anyways, rebooted fine. But settings retrieval still takes about 13-14 seconds 2010-04-01T12:07:26 I have only about 85-86 connected users through ejabberd 2010-04-01T12:07:40 a little low compared to the 128 referenced in the IRC log above 2010-04-01T12:08:15 autogen still went to sleep 2010-04-01T12:08:23 Time to see about increasing the timeout to maybe around 20 seconds. 2010-04-01T12:09:58 boomshakalaka 2010-04-01T12:10:05 20 second timeout allowed it to progress to the next point. 2010-04-01T12:11:48 Attempting to build a client session as a server Session ID [1270138235.354162093.53624608221], remote_id [opensrf@private.localhost/opensrf.settings_drone_at_evergreen.arch.tamu.edu_5673] at /usr/lib64/perl5/site_perl/5.8.8/OpenSRF/AppSession.pm line 98. 2010-04-01T12:11:48 Exception: OpenSRF::EX::Session 2010-04-01T11:10:51 OpenSRF::Transport /usr/lib64/perl5/site_perl/5.8.8/OpenSRF/Transport.pm:120 Session Error: Transport::handler(): No AppSession object returned from server_build() 2010-04-01T12:11:50 Still pretty pathological 2010-04-01T12:12:46 That was right after Updating OrgTree HTML 2010-04-01T12:16:40 *** jenny has joined #evergreen 2010-04-01T12:18:54 *** jamesrf has joined #evergreen 2010-04-01T12:22:34 So I'm working on my PHP class for OpenSRF (if someone tells me there's already one made, then I quit), and I'm sending [{"method":"open-ils.auth.authenticate.init","params":[]}] to osrf-http-translator, but getting nothing (Content-Length: 0) back. Does my "srfMessage object" look correct, or am I going the wrong way on this? 2010-04-01T12:27:37 for the translator, you probably need something more like the JSON in the section of http://evergreen-ils.org/~denials/OpenSRF_intro_part1.html#_message_body_format 2010-04-01T12:28:17 e.g. a wrapping hash where "__c": is "osrfMessage" 2010-04-01T12:29:30 emrikol: see also math_client_curl.sh in OpenSRF trunk 2010-04-01T12:29:56 http://svn.open-ils.org/trac/OpenSRF/browser/trunk/examples/math_client_curl.sh 2010-04-01T12:30:08 emrikol: emrikol yeah, you need to have all the object infrastructure in place before start constructing raw messages 2010-04-01T12:56:48 ahh, I pasted the wrong thing, that's why :) 2010-04-01T12:56:54 I thought that looked rather short 2010-04-01T12:57:29 [{"__c":"osrfMessage","__p":{"threadTrace":0,"type":"REQUEST","payload":{"__c":"osrfMethod","__p":{"method":"open-ils.auth.authenticate.init","params":[]}},"locale":"en-US"}}] 2010-04-01T12:57:33 is what I was actually using 2010-04-01T12:57:43 I don't know why I pasted just the chunk 2010-04-01T12:58:19 (Must've been messing around with it somewhere else?) 2010-04-01T13:00:05 I wonder if it's something wrong with my headers I'm sending... 2010-04-01T13:03:13 "Content-Type: application/x-www-form-urlencoded" 2010-04-01T13:03:13 "X-OpenSRF-thread: 13609100251270141368" 2010-04-01T13:03:13 "X-OpenSRF-service: open-ils.auth" 2010-04-01T13:05:35 Do I need a X-OpenSRF-xid? 2010-04-01T13:07:26 *** sfortin has quit IRC 2010-04-01T13:08:09 emrikol: you don't need to create one, but you need to be able to receive one and attach it to a session to send with any other requests 2010-04-01T13:08:17 IIRC 2010-04-01T13:09:16 All I'm getting back is: 2010-04-01T13:09:21 Date: Thu, 01 Apr 2010 17:02:18 GMT 2010-04-01T13:09:21 Server: Apache/2.2.9 (Debian) mod_ssl/2.2.9 OpenSSL/0.9.8g mod_perl/2.0.4 Perl/v5.10.0 2010-04-01T13:09:21 Cache-Control: max-age=2592000 2010-04-01T13:09:21 Expires: Sat, 01 May 2010 17:02:18 GMT 2010-04-01T13:09:21 Content-Length: 0 2010-04-01T13:09:21 Content-Type: text/plain 2010-04-01T13:10:19 mmm... shold be a osrfApp (again, IIRC) in the osrfMessage object 2010-04-01T13:10:33 *** pmplett has joined #evergreen 2010-04-01T13:11:08 oh 2010-04-01T13:11:10 duh 2010-04-01T13:11:11 no 2010-04-01T13:11:13 emrikol: there was a bug with OpenSRF and the http-translator where you did need to provide a thread or xid that I fixed 2010-04-01T13:11:16 that's X-OpenSRF-service: 2010-04-01T13:11:24 not sure if it's in a released version though 2010-04-01T13:11:40 there you go :) 2010-04-01T13:12:34 http://svn.open-ils.org/trac/OpenSRF/changeset/1912 2010-04-01T13:12:42 So even if I have the X-OpenSRF-thread, I should send an X-OpenSRF-xid as well? 2010-04-01T13:13:22 no - it was thread 2010-04-01T13:13:35 I couldn't remember which one, but now I do :) 2010-04-01T13:14:18 So I should be okay by having the thread in there. Hmm... 2010-04-01T13:14:21 OH CRAP! 2010-04-01T13:14:38 This is SSL. I need to see if my curl is set for that 2010-04-01T13:15:10 yep :( 2010-04-01T13:15:19 heh 2010-04-01T13:15:25 (Well, yeah stupid, you're getting headers back. It's connecting) 2010-04-01T13:17:11 *** jenny has quit IRC 2010-04-01T13:19:14 does demo.gapines or any other demo have an osrf-http-translator that I could try also? 2010-04-01T13:22:15 could use a virtual image for the server, would let you more easily see what's happening on the other end 2010-04-01T13:23:43 Good point. I'll have to wait until tomorrow to try that. Where I'm at today, I've only got a piddly little 1.4Ghz Athlon XP. It's slow enough the way it is. 2010-04-01T13:24:12 you might be able to do something acq.open-ils.org, but I'm not sure how old it is or what state it's in 2010-04-01T13:25:02 dev.gapines.org is running 1.4-ish, I think; not sure when osrf-http-translator was introduced 2010-04-01T13:26:42 emrikol: you could point at http://laurentian-test.concat.ca - although only for public services, I can't hand out any credentials there 2010-04-01T13:27:01 * dbs just tried math_client_curl.sh against that server, and it worked 2010-04-01T13:29:52 I am an idiot 2010-04-01T13:30:03 emrikol: you'll need a param, eh? 2010-04-01T13:30:04 I forgot osrf-msg= 2010-04-01T13:30:15 "params":["seeddata"] 2010-04-01T13:30:39 heh 2010-04-01T13:31:44 {"status":"Not enough params for method open-ils.auth.authenticate.init / service open-ils.auth","statusCode":"404"} :) I'm just happy to get something back 2010-04-01T13:31:58 emrikol++ 2010-04-01T13:49:39 POP QUIZ! ... ok, not really ... STRAW POLL! 2010-04-01T13:50:22 bib record ownership (by a location) like serial record ownership ... should it restrict attaching asset.call_number rows to just here-or-deeper? 2010-04-01T13:52:23 I'm strongly inclined to say "yes, miker, it should" 2010-04-01T13:52:37 but then I'd be talking to myself, and that's just strange 2010-04-01T13:53:51 note, that's just semantic right now ... it could even be an OU setting (allowed or not) 2010-04-01T14:02:25 *** jenny has joined #evergreen 2010-04-01T14:07:39 no? nothing? 2010-04-01T14:07:56 phone 2010-04-01T14:11:39 phone 2010-04-01T14:13:40 okay... back and... yeah, if sites are going to go with a "git-yer-hands-off-my-bibs" policy, that restriction makes sense to me 2010-04-01T14:15:57 *** grantjohnson has quit IRC 2010-04-01T14:17:51 miker_: should be a setting - one OU may be the centralized cataloging agency, or the most-trusted-of-the-lot, but be preparing bibs that anybody is allowed to attach holdings to 2010-04-01T14:18:59 gmcharlt: in that case, the cataloguers could be cataloguing at the consortial level 2010-04-01T14:20:15 that's my thinking too .. maybe "ownership" is the wrong word ... "availablility" is unclear, but is more in line with what's in my head 2010-04-01T14:20:17 * dbs tries to fight against a hard-to-figure-out-what-goes-wrong-if-it-gets-set-OU-setting-unless-we-have-a-nice-clear-failure-message-that-explains-the-reason-and-how-to-correct-it 2010-04-01T14:21:23 cat.trust-no-1 = 1 2010-04-01T14:21:23 dbs: well, personally, I'd be happer with good edit history and the ability to view bib record diffs in the client rather than the command-and-control model that bib record ownership implies 2010-04-01T14:21:40 gmcharlt: I dig that 2010-04-01T14:22:05 but consortial that want bib record ownership *really* want it in my experience 2010-04-01T14:23:37 I think the notion that the bib should be owned at the consortial level makes sense and is easy to explain, so I'm not opposed to that necessarily, but I wonder if it would be clearer to separate the notion of ownership-qua-who-gets-to-edit vs. availablity-qua-who-gets-to-attach-holdings 2010-04-01T14:23:37 ok ... so, originally, I had planned 2 fields: owner and share_depth 2010-04-01T14:24:44 the former decides who can edit the MARC, and the latter expresses, indirectly, where it can be used (attached to) 2010-04-01T14:25:24 heh ... 2010-04-01T14:25:50 so, I'll go with that, then 2010-04-01T14:26:04 dbs: objections? 2010-04-01T14:26:21 gmcharlt: that should cover your proposed cases, yes? 2010-04-01T14:26:48 also, share_depth would be restricted to owner-or-higher 2010-04-01T14:27:46 well, I don't know - it really depends on who wants it - one wrinkle that some consortia might use is that nobody but the owner is allowed to edit the bib record, but anybody can add notes fields and the like scoped to their library with a $5 2010-04-01T14:28:09 * dbs vomits 2010-04-01T14:28:24 moodaepo: ^^ 2010-04-01T14:29:11 Is there any way to turn *OFF* or at least ratchet down the spam filtering on EG mail lists? 2010-04-01T14:29:16 it sounds good to me miker_ 2010-04-01T14:29:20 We came from a no-shared-bibs model and embraced shared bibs, so I'm probably the wrong person to ask 2010-04-01T14:29:37 The ***SPAM*** false positive rate is exceedingly high. 2010-04-01T14:29:44 (to be clear, I was vomiting on gmcharlt's wrinkle, not miker_'s proposal) 2010-04-01T14:29:56 dbs: I just report the news ;) 2010-04-01T14:30:22 gmcharlt: ***SPAM*** ***SPAM*** ***SPAM*** I know, I'm not blaming you :) 2010-04-01T14:31:25 The top 11 threads in my box, 6 are false positives. And that includes 3 non-EG-list messages. 2010-04-01T14:31:26 chrissharp123: ^^^ re: spam ? 2010-04-01T14:32:19 miker_: but to answer your question, yes, I'm cool with that, although even better if the default share depth could could be a staff user session setting or preference to help people who have to catalog both for their own library and on behlaf of a consortium 2010-04-01T14:33:01 could be worse - at least nobody's talking about the RLIN model of base bib record + per-library localized version 2010-04-01T14:33:30 gmcharlt: I think that's reasonable to add 2010-04-01T14:36:41 Just to mention (just catching up), but I think that our catalogers here want the ability like what Galen described earlier. To have owners edit bibs, but allow others to add notes, etc. 2010-04-01T14:37:05 So that sounds cool. 2010-04-01T14:38:14 bshum: well, that's not was I was saying would be reasonable to add ;) ... however, there's infrastructure for extra-bibular (ha! what a word!) notes now. just no UI or permissions 2010-04-01T14:39:53 bshum: ahhh, I *knew* there was a reason I got violently ill when I was in your neck of the woods! 2010-04-01T14:40:11 dbs: Heh :) 2010-04-01T14:40:17 I'm just the messenger. 2010-04-01T14:41:01 miker_: would you be horrified if I proposed replacing the MODS-based indexing for subjects with MARC-based indexes? 2010-04-01T14:42:00 dbs: somewhat, yes ;) ... do you have some replacement xpath to point at? 2010-04-01T14:42:15 miker_: I think you have a band name there: MikeR and the Extra-Bibular Catalogers 2010-04-01T14:42:28 check out http://laurentian.concat.ca/opac/en-CA/skin/lul/xml/rdetail.xml?r=241097 - our friend MARC2MODS* doesn't bother including 600t so the corresponding subject links result in 0 hits, which is counter-intuitive 2010-04-01T14:43:12 dbs: for handmaid's tale, you mean? 2010-04-01T14:43:17 aye 2010-04-01T14:43:57 I need to conjure up some xpath for this anyway, as I've committed to fixing that problem by Tuesday morning, but 2010-04-01T14:44:21 yeah, I mean, I can't get too worked up over indexing matchpoints, really (I was lying about being horrified) 2010-04-01T14:45:15 dbs: another approach would be to use the 3.3 marc-to-mods stylesheet, which slurps in the 600$t 2010-04-01T14:45:24 something like //marcxml:datafield[@tag="600" or @tag="610" or @tag="611"]/marcxml:subfield[@code!=4] for subject:name for example 2010-04-01T14:45:53 gmcharlt: yeah... now that they fixed some of the stuff they broke with URLs 2010-04-01T14:46:22 actually, 3.3 is the default in trunk ... I guess we need to update the xslt 2010-04-01T14:46:50 huh, I thought we had reverted that? 2010-04-01T14:47:15 not the default for the format column on config.metabib_field, no 2010-04-01T14:47:30 just on the actual stock definitions 2010-04-01T14:47:38 the MODS transforms are a great starting point, but debugging why something doesn't work, and explaining that - and then fixing it - is _not fun_ 2010-04-01T14:47:54 *** moodaepo has quit IRC 2010-04-01T14:47:57 but, updating 3.3 and adding 3.4 would be good, IMO 2010-04-01T14:48:03 certainly 2010-04-01T14:49:06 I just get blank stares from cataloguers and librarians when I explain indexing via MODS, whereas with MARC at least we have something to communicate about (as sad as that is) 2010-04-01T14:49:31 thought occurs - add a view-as-transformed-to-MODS-or-whatever widget in the MARC editor 2010-04-01T14:49:53 * dbs looks at http://www.loc.gov/standards/mods/mods-conversions.html - wrong site? 2010-04-01T14:50:01 that'd be simple enough (not volunteering) 2010-04-01T14:50:18 dbs: right one 2010-04-01T14:50:29 or did the MODS people only announce the 3.4 stuff on the list? *sigh* 2010-04-01T14:51:15 so much for my plan to introduce some short cache times + dojo.fx for april fools' day 2010-04-01T14:51:20 too busy "working" 2010-04-01T14:51:31 maybe 3.4 isn't officially finalized yet? 2010-04-01T14:52:49 "Look for a draft 3.4 Schema for community review in January" from Jenn Riley, Dec 2009 2010-04-01T14:53:37 doesn't look like it happened 2010-04-01T14:53:57 hey ... while we're talking about marc/mods/etc ... proposal: move the marc field off the record_entry table onto a new table that has an id (same as the bre table), the original data, the type (mods, onix, dc, crayon-scratchings, whatever), and an auto-transformed-to-marcxml blob. then, move biblio.record_entry out of the way and replace it with an updateable view that stitches the pile-of-data table and the info-about-the-pile-of-data-table together - 2010-04-01T14:54:23 not proposing that for this very second ... just testing the waters 2010-04-01T14:55:49 sounds reasonable once we're in a position to get serious about supporting more than one metadata schema 2010-04-01T14:56:21 gmcharlt: IMO, that's the first step 2010-04-01T14:56:39 not sure it's much of a win before we're ready to go further down that road 2010-04-01T14:57:28 indirect benefit: speedier searching (smaller/faster lookups for deletedness and transendenceness of records) 2010-04-01T14:57:29 Other than being able to claim support for more than MARC? Evergreen 2.0: "Much more than MARC" 2010-04-01T14:57:41 Mmm, that's nicer 2010-04-01T14:59:05 well, there'd be two benefits - one is it would help in an effort to support MARC formats other than MARC21 (UNIMARC in particular); 2nd would be in principle letting library-bibliographic, digital library, and archival metadata live together in one big happy glop 2010-04-01T14:59:33 gmcharlt: zacly 2010-04-01T15:00:00 it would still filter everything through the MARC lense, but at least the data could get in there 2010-04-01T15:00:18 but, again, that's later, and a direct benefit/reason 2010-04-01T15:02:39 @eightball should I wait until April 8 to register for eg2010? 2010-04-01T15:02:39 dbs: Yes! 2010-04-01T15:02:43 Done and done. 2010-04-01T15:06:11 back to record ownership ... owner and share_depth will be nullable. if owner is null, top of tree assumed. if share depth is null, no sharing assumed. eh? 2010-04-01T15:07:20 *** moodaepo has joined #evergreen 2010-04-01T15:10:49 default will be owning_ou=null, share_depth=1 or the like? 2010-04-01T15:11:03 err, share_depth=0? 2010-04-01T15:11:25 * dbs displays his usual depth confusion 2010-04-01T15:12:04 null,null == owner=1,depth=0 2010-04-01T15:12:31 14,null == owner=14,depth=2 (if 14 is a branch) 2010-04-01T15:12:41 does that make sense? 2010-04-01T15:14:38 yep. I'm just saying the out-of-the-box defaults won't change, right? 2010-04-01T15:14:47 exactly 2010-04-01T15:15:06 cool 2010-04-01T15:15:12 and, more to the point, upgraded DBs will just work 2010-04-01T15:15:54 the most important point! 2010-04-01T15:21:15 well, that was easy 2010-04-01T15:22:15 gmcharlt: Was away. I'm pretty sure our folks would ++ your comments about bib 'ownership' in a consortia (13:27:46) and after, along with the chimes from bshum 2010-04-01T15:38:51 Hmm, "owning_lib" on serial.record_entry and asset.call_number, "owner" on biblio.record_entry and various acq / config tables; looks like I picked the wrong noun 2010-04-01T15:40:10 dbs: I think asset.copy_location uses owning_lib 2010-04-01T15:40:15 so, there's precedent 2010-04-01T15:41:22 yeah, just more of the source vs. record game that I always play in my head :) 2010-04-01T15:42:13 * phasefx 's favorite is fleshing columns with _id in the label :) 2010-04-01T15:43:30 $foo->bar_id->id 2010-04-01T15:44:50 phasefx: do we have those? 2010-04-01T15:45:11 there's stuff like eg_bib_id and eg_copy_id in some acq tables 2010-04-01T15:45:25 * berick also hit those and stuttered 2010-04-01T15:46:38 permission.usr_object_perm_map.object_id 2010-04-01T15:46:42 I object! 2010-04-01T15:49:48 ahh, yeah 2010-04-01T15:49:50 sorry bout those 2010-04-01T15:58:50 *** collum has quit IRC 2010-04-01T16:00:12 HOT++ 2010-04-01T16:00:13 *** eby has joined #evergreen 2010-04-01T16:00:53 miker_ / berick : either of you around? 2010-04-01T16:01:09 eby: I am, sir 2010-04-01T16:01:37 miker_: PM 2010-04-01T16:02:54 *** jamesrf has quit IRC 2010-04-01T16:03:15 * berick looks up, then back down again 2010-04-01T16:03:33 heads-down, berick, you've got a presentation to put together! 2010-04-01T16:04:37 heads-down berick, you've got to finish what you're doing so you can start thinking about a presentation 2010-04-01T16:07:24 berick: clearly would be easier if "heads-down berick" were a doppelganger 2010-04-01T16:07:56 Well, it's taken a few days of working off and on, but I've managed to get a semi-working PHP Class for OpenSRF. I can authenticate and get back an authcode! 2010-04-01T16:08:20 nice 2010-04-01T16:08:24 dbs: fyi i went through your article in progress and it was a worthwhile read 2010-04-01T16:08:27 gmcharlt: hah, that would also mean i'm not talking to myself (via irc, no less) 2010-04-01T16:08:40 dbs: coworker got a lot out of it as well. so you're on the right track 2010-04-01T16:08:49 * dbs assumes that berick is coding a Dojo extension that generates PowerPoint output as part of the acq work 2010-04-01T16:08:54 emrikol++ 2010-04-01T16:09:07 emrikol++ 2010-04-01T16:09:14 emrikol++ 2010-04-01T16:09:22 now you just need to run it against the massive set of unit tests to see what needs fixing! hahaha :) 2010-04-01T16:09:29 dbs-- 2010-04-01T16:09:32 lol 2010-04-01T16:09:43 dbs++ # you've found somebody to write them for us! ;) 2010-04-01T16:10:21 emrikol: it's definitely cool that you've gone the http-translator route for now; somebody else can probably refactor it to optionally use the XMPP transports later 2010-04-01T16:10:44 eby: glad to hear it! 2010-04-01T16:11:22 * miker_ tests re-ingest of ~11k records via in-db ingest 2010-04-01T16:12:40 dbs: would it be better to work via xmpp? All I really had to go off was the Javascript client (opensrf.js). I guess that's almost cheating :) 2010-04-01T16:13:33 *** natschil has joined #evergreen 2010-04-01T16:14:15 better in some network environments, I'd imagine, but not in others 2010-04-01T16:15:03 emrikol: it'd be much faster for a php script living inside apache right next to the opensrf network 2010-04-01T16:16:30 So it sounds like it's probably not necessary for my needs, as they should be pretty low traffic 2010-04-01T16:17:22 *** sfortin has joined #evergreen 2010-04-01T16:17:58 emrikol: this is mostly for supporting availability look-up / placing holds and the like through VuFind, yeah? 2010-04-01T16:19:04 Mostly, but not through VuFind. 2010-04-01T16:19:31 I'm sure the transport layer could be a configurable option in your implementation, in any case. Let somebody else worry about XMPP if they need the speed (or you, if you determine that later) 2010-04-01T16:20:17 emrikol: oh, okay - eventually those folks (and the ILS-DI, Janglers, etc) would probably be interested too 2010-04-01T16:20:50 * eby makes note for sopac 2010-04-01T16:21:19 *** Meliss has quit IRC 2010-04-01T16:22:01 I might have a look at XMPP once I get this going steady. On a somewhat related note, short of sifting through the perl modules (correct?) and sniffing the OPAC, is there any other place that lists services, methods, and their required params? 2010-04-01T16:22:04 emrikol: and atheos will heart you, I think 2010-04-01T16:22:16 emrikol: docgen 2010-04-01T16:23:10 http://dev.gapines.org/opac/extras/docgen.xsl for example 2010-04-01T16:23:25 http://dev.gapines.org/opac/extras/docgen.xsl?service=open-ils.actor&all=on&offset=0&limit=25 2010-04-01T16:23:49 atz is in a method doc clean-up blitz, bless his heart 2010-04-01T16:23:50 oh hell, I'm in love 2010-04-01T16:23:57 That will save a ton of time! 2010-04-01T16:24:02 emrikol: copy src/extras/docgen.xsl from the OpenSRF package into /openils/var/web/opac/extras/ 2010-04-01T16:24:32 note, dev.gapines.org is out of date by many months 2010-04-01T16:24:37 what miker_ said 2010-04-01T16:25:30 * dbs makes a mental note to add that to the OpenSRF intro tutorial and the default eg conf for OpenSRF, for the millionth thime 2010-04-01T16:26:32 Once again, thanks everyone. I'm headed out for the day, but I'll be sure to look at docgen when I come back to this problem. 2010-04-01T16:27:06 btw, we're past our two-month trial period on LaunchPad, and there seems to be a gittish move afoot, so perhaps we should convene at some point to decide what we're going to do. 2010-04-01T16:27:26 maybe, say, at eg2010 for those who will be there? 2010-04-01T16:29:16 dbs: i had kind of assumed the hackfest might devolve into a dev meeting 2010-04-01T16:29:28 *** rjackson-isl has quit IRC 2010-04-01T16:29:42 berick-- 2010-04-01T16:29:44 hah 2010-04-01T16:29:54 devolve :) 2010-04-01T16:31:15 an 8-hour dev meeting! AWESOME 2010-04-01T16:31:30 * dbs cues up some DEVO 2010-04-01T16:31:37 hah 2010-04-01T16:31:39 I have many (some impolitic) thoughts to share on git 2010-04-01T16:32:14 I will wear my asbestos undies to eg10 2010-04-01T16:32:16 it's such a short conference (everyone i know is leaving friday right when it's over). the hackfest day seems like the only time 2010-04-01T16:35:43 miker_: I'm no fan of git myself - albeit much of that coming from ignorance and initial impressions - but willing to embrace it if it results in an always-stable trunk with lots and lots of topic branches for development and stabilization 2010-04-01T16:37:03 berick: I can stay later than Friday (and could probably convince kbeswick and r123, my car-poolies, likewise) 2010-04-01T16:37:44 dbs: alas, i probably can't 2010-04-01T16:37:59 (at least, that's the promise of DVCS, the reality depends on the actual usage I suppose) 2010-04-01T16:38:13 that's why we moved to git here 2010-04-01T16:38:24 took awhile to get head around the change 2010-04-01T16:38:54 *** jamesrf has joined #evergreen 2010-04-01T16:39:26 I've become a fan of rewriting history with git rebase -i 2010-04-01T16:39:45 dbs: an "always stable trunk" is spelled rel_1_6 ;) 2010-04-01T16:39:49 * miker_ ducks 2010-04-01T16:39:55 and runs away for the evening 2010-04-01T16:40:03 miker_: that's my target these days 2010-04-01T16:40:07 gnite 2010-04-01T17:00:41 *** BobW has left #evergreen 2010-04-01T17:12:47 *** neraath has left #evergreen 2010-04-01T17:17:19 Bah, what a day: nary a single minute of work on SPaRe (Self Password Reset) 2010-04-01T17:17:34 * dbs homes 2010-04-01T17:17:39 *** dbs has quit IRC 2010-04-01T17:42:17 *** bshum has quit IRC 2010-04-01T17:43:16 *** natschil has quit IRC 2010-04-01T18:06:27 *** jenny has left #evergreen 2010-04-01T18:31:07 *** sfortin has quit IRC 2010-04-01T18:56:43 *** r123 has quit IRC 2010-04-01T19:51:34 *** jamesrf has quit IRC 2010-04-01T21:33:50 *** jamesrf has joined #evergreen 2010-04-01T23:12:26 *** jamesrf has quit IRC