2010-01-06T00:16:20 *** mck9 has left #evergreen 2010-01-06T00:42:38 *** pmplett has quit IRC 2010-01-06T00:54:00 *** frzosima has joined #evergreen 2010-01-06T00:54:27 *** frzosima has quit IRC 2010-01-06T01:11:59 *** dbs has quit IRC 2010-01-06T01:16:06 *** pmplett has joined #evergreen 2010-01-06T01:54:01 *** pmplett has quit IRC 2010-01-06T07:49:42 *** sfortin has joined #evergreen 2010-01-06T08:00:03 *** mck9 has joined #evergreen 2010-01-06T08:05:46 *** natschil has joined #evergreen 2010-01-06T08:59:55 *** Meliss has joined #Evergreen 2010-01-06T09:00:31 *** bshum has joined #evergreen 2010-01-06T09:18:38 *** jenny has joined #evergreen 2010-01-06T09:24:45 *** brendan_ga has quit IRC 2010-01-06T09:25:36 *** r123 has joined #evergreen 2010-01-06T09:35:02 *** jenny has left #evergreen 2010-01-06T09:40:48 *** brendan_ga has joined #evergreen 2010-01-06T10:10:32 TypeError: document.getElementById("commonStrings").getString is not a function when registering a workstation, anyone? 2010-01-06T10:10:48 ran an autogen, ou is setup properly, user has proper permissions 2010-01-06T10:13:58 any chance of network issues, filtering, etc? 2010-01-06T10:14:10 phasefx_: thats what i am thinking too 2010-01-06T10:14:31 because i can register just fine with the same user on my end, so that should eliminate an org or user permission problem 2010-01-06T10:15:31 yep, some cyber sitter software 2010-01-06T10:15:40 apache should be showing a hit against server/local/en-US/common.properties. If that were to fail, I could see that error happening 2010-01-06T10:16:12 local -> locale, even 2010-01-06T10:24:08 *** alxp has joined #evergreen 2010-01-06T10:56:18 *** natschil has quit IRC 2010-01-06T11:02:38 *** phasefx3 has joined #evergreen 2010-01-06T11:22:36 *** dbs has joined #evergreen 2010-01-06T11:41:54 *** StephenGWills has quit IRC 2010-01-06T12:09:02 *** jenny has joined #evergreen 2010-01-06T12:09:24 *** jenny has left #evergreen 2010-01-06T12:46:11 *** bshum has quit IRC 2010-01-06T12:50:18 *** jenny1 has joined #evergreen 2010-01-06T12:50:26 *** jenny1 has left #evergreen 2010-01-06T13:11:42 *** natschil has joined #evergreen 2010-01-06T13:18:00 *** grantjohnson has joined #Evergreen 2010-01-06T13:22:01 * dbs adds a big bold warning to http://evergreen-ils.org/dokuwiki/doku.php?id=opensrf:1.2:install 2010-01-06T13:56:44 *** leed has quit IRC 2010-01-06T13:56:50 *** leed has joined #evergreen 2010-01-06T13:57:20 *** gdunbar_ has joined #evergreen 2010-01-06T14:01:48 The opensrf javascript gateway is asynchronous, right? 2010-01-06T14:02:27 *** gdunbar has quit IRC 2010-01-06T14:02:39 *** gdunbar_ is now known as gdunbar 2010-01-06T14:03:40 (I don't see how it could be anything else though) 2010-01-06T14:03:51 natschil: not sure I follow. You can make an asynchronous request against any http source with modern web browsers, etc. The gateway itself waits on opensrf responses and can eventually time out 2010-01-06T14:04:49 phasefx_: how does it pause to get request.result() though? 2010-01-06T14:06:31 the newer javascript stack for talking OpenSRF over http supports streaming results, but that's still one sustained connection via http 2010-01-06T14:07:14 basically the xmlhttprequest object behind the scenes fires a callback for every response coming in 2010-01-06T14:07:40 phasefx_: ok 2010-01-06T14:08:24 does that make sense? I'm sure I don't have all the nomenclature right 2010-01-06T14:10:52 phasefx_: kind of... I'm just wondering whether the old Request() way is asynchronous or synchronous, as it appears to be synchronous due to the fact that I can run r = new Request(args);r.send(true);r.result(), and it fetches r.result ( or does the true mean it's synchronous), in a synchronous way without callbacks 2010-01-06T14:14:10 you should be able to also do asynchronous by setting a callback, etc. 2010-01-06T14:15:59 the staff client predominantly uses RemoteRequest.js, with which you can do stuff like r = new RemoteRequest( app, name ); r.setSecure(true); r.addParam( session ); r.setCompleteCallback( some_func ); r.send(false); 2010-01-06T14:17:01 and RemoteRequest.js is just wrapping a browser's native XMLHttpRequest functionality 2010-01-06T14:26:05 *** StephenGWills has joined #evergreen 2010-01-06T14:27:17 *** Dmagick has quit IRC 2010-01-06T14:33:42 phasefx_: ok, thanks...I'm guessing that r.send(argument) takes the synchronousity of the request as the argument 2010-01-06T14:36:16 natschil: you might want to go the http translator route in any case: http://evergreen-ils.org/~denials/workshop.html#_javascript 2010-01-06T14:36:56 with RemoteRequest.js at least. I'm not sure about the new Request example you used, and the underlying .send() method with XMLHttpRequest objects uses a paramater for POST data, I think, not blocking versus non-blocking 2010-01-06T14:40:12 dbs: that looks useful...I know about the http translator route, but I'm less familiar with it, so your document looks very useful. However, sometimes I find it convenient to simply "call" a function using the old RemoteRequest way 2010-01-06T14:41:13 natschil: I found the number of requirements to use the old RemoteRequest way was overwhelming when I tried to document that route 2010-01-06T14:41:42 dbs: what do you mean with "requirements"? 2010-01-06T14:42:01 dependency on top of dependency (JS libraries getting pulled in)... but that might have been more on the Evergreen side of things 2010-01-06T14:42:58 dbs: I see. 2010-01-06T14:44:21 * phasefx_ includes the kitchen sink with the XUL side of things, so never noticed. "I would have expected RemoteRequest.js and some JSON/fieldmapper stuff 2010-01-06T14:47:27 *** Dmagick has joined #Evergreen 2010-01-06T14:47:37 dojo.require('DojoSRF'); ... done and done ;) (until you want to use registered fieldmapper classes, but that's just dojo.require('fieldmapper.AutoIDL');) 2010-01-06T14:48:22 strange...it seems that if I have another XMLHttpRequest running and I create a new RemoteRequest, this somehow causes it loop indefinetly trying to retrieve the session... 2010-01-06T14:48:26 is that the minimum for fieldmapper.standardRequest? 2010-01-06T14:48:28 * natschil goes to investigate 2010-01-06T14:49:05 natschil: I would lobby for fieldmapper.standardRequest as a RemoteRequest replacement 2010-01-06T14:49:23 miker_: yeah, I was trying to avoid Dojo for the minimal case 2010-01-06T14:49:49 but boy howdy does it make things easier 2010-01-06T14:51:15 phasefx_: does it work like the old RemoteRequest ? 2010-01-06T14:51:22 phasefx_: probably 2010-01-06T14:51:48 natschil: very nearly, yes 2010-01-06T14:51:52 * dbs tries to figure out how an overdue notice came from library A, to a patron with a home_ou of library B, for items that have a circ_lib and owning_lib of library C 2010-01-06T14:52:05 you don't have to instantiate an object with fieldmapper.standardRequest 2010-01-06T14:52:17 dbs: action.circulation.circ_lib == A? 2010-01-06T14:52:52 the javascript example under http://evergreen-ils.org/~denials/workshop.html#_adding_an_idl_entry_for_resolverresolver is a more dojo-ized approach 2010-01-06T14:53:15 miker_: good thought - shouldn't be, but anything's possible. I'll dig. miker_++ 2010-01-06T14:53:31 natschil: http://svn.open-ils.org/trac/ILS/browser/trunk/Open-ILS/xul/staff_client/server/patron/staged.js#L268 2010-01-06T14:54:02 phasefx_: does it reset the authtimer? 2010-01-06T14:55:59 I don't know what determines that. I'm not sure whether it is method specific or whether any method that makes use of a session key resets the session timeout 2010-01-06T14:56:10 the latter sounds probable 2010-01-06T14:56:21 so it's not dependent on client side libraries, in any case 2010-01-06T14:56:38 phasefx_: I know that the old Request() way of doing things reset the timeout...it should be easy to simply add that to fieldmapper.standardRequest though if that is needed. 2010-01-06T14:56:56 well, what timeout are you referring to? 2010-01-06T14:57:00 miker_: ah, action.circulation checkin_lib = A, circ_lib = C, good fun 2010-01-06T14:57:56 natschil: the auth timer is reset each time the session is retrieved from memcache 2010-01-06T14:58:15 miker_: phasefx_: I mean the client side auth time 2010-01-06T14:58:27 dbs: huh ... were you intending to use checkin lib? 2010-01-06T14:59:11 miker_: not in this manner, no 2010-01-06T14:59:58 natschil: I'm not sure if any of the other network stacks other than RemoteRequest.js uses a javascript timeout in their implementations 2010-01-06T15:00:49 phasefx_: doesn't the OPAC have a timeout somewhere though? 2010-01-06T15:01:05 not even sure if the one I see in RemoteRequest is wired up 2010-01-06T15:01:16 *** alxp has quit IRC 2010-01-06T15:01:37 natschil: oh, that would all be OPAC specific 2010-01-06T15:01:37 natschil: you mean the auto-logout popup thingy? that's just a page-wide setTimeout alert 2010-01-06T15:02:06 loading any opac page, while logged in, causes the session object to be fetched, resetting the timer 2010-01-06T15:02:18 it's controlled by an org unit setting 2010-01-06T15:02:25 "it" being the timeout 2010-01-06T15:04:12 miker_: so nothing other than the Request() way of calling opensrf resets the timeout, other than loading an opac page? 2010-01-06T15:04:49 um ... 2010-01-06T15:05:15 retrieving the session object from the auth service, using any mechanism, resets the timeout 2010-01-06T15:05:54 miker_: sorry, s/timeout/auth timer in the opac/ 2010-01-06T15:06:37 Request is one way, the DojoSRF api is another ... there are methods in the openils.User (IIRC) dojo package that will retrieve the session, I believe 2010-01-06T15:07:26 miker_: ok, I see..haven't looked into those so much...thanks for the info 2010-01-06T15:07:48 dbs++ # that opensrf page is really useful 2010-01-06T15:09:55 natschil: some day I might complete it, and maybe people who know more than me will offer feedback :) 2010-01-06T15:15:20 *** natschil has quit IRC 2010-01-06T15:18:10 *** OCLS-adm has joined #evergreen 2010-01-06T15:20:10 Good afternoon, evergreen brethern. Orange County (FL) Lib Syst. seeking assistance with getting our Evergreen sandbox going... 2010-01-06T15:21:02 hi OCLS-adm 2010-01-06T15:22:20 Hola 2010-01-06T15:23:47 Hello, gmcharlt and dbs. I've followed the docs for installing OpenSRF and installing Evergreen. Everything looked rosy... 2010-01-06T15:26:09 On what distribution? 2010-01-06T15:30:09 When I tested the connection using srfsh per the docs, I was able to log in as admin. When I ran the staff client under XULRunner, I got an error with the same creds -- network or server failure. [evergreen 1.6.0.0) 2010-01-06T15:30:42 Running it in XULRunner on the localhost. 2010-01-06T15:32:48 Network failure: status = 200 2010-01-06T15:32:54 how about logging in through the OPAC? (warning: using admin/open-ils against a stock OPAC will ask you to change the password) 2010-01-06T15:35:23 Hello phasefx_. I haven't gotten that far yet and don't have how-to docs yet. 2010-01-06T15:35:27 *** pmplett has joined #evergreen 2010-01-06T15:37:18 OCLS-adm: could you paste the console output from xulrunner to http://paste.lisp.org/new/evergreen ? 2010-01-06T15:39:32 OCLS-adm: did you restart the Apache server? 2010-01-06T15:39:55 if Apache was running before the OpenSRF services, then connection via the OPAC or staff client will fail miserably 2010-01-06T15:42:34 OCLS-adm pasted "xulrunner error" at http://paste.lisp.org/display/93074 2010-01-06T15:44:27 So do I have to just restart Apache? It was running before the OpenSRF services because it was installed at OS install. Do I have to start fresh and install Apache as part of the OpenSRF or Evergreen install? 2010-01-06T15:45:55 OCLS-adm: nope, just restart it 2010-01-06T15:57:18 Restarted apache. Restarted xulrunner and Web client. Same error with both. Web logon claims "Error Communicating with Authentication Server". 2010-01-06T15:59:21 *** Meliss has quit IRC 2010-01-06T16:05:39 *** grantjohnson has quit IRC 2010-01-06T16:19:12 *** sfortin has quit IRC 2010-01-06T16:31:39 *** OCLS-adm_ has joined #evergreen 2010-01-06T16:31:55 *** OCLS-adm has quit IRC 2010-01-06T16:31:56 *** OCLS-adm_ is now known as OCLS-adm 2010-01-06T16:32:36 *** jenny has joined #evergreen 2010-01-06T16:38:35 If I could get the base install running right and be able to log into it, I would be willing to make the image (VMWare vSphere 4.0, Debian Lenny, Evergreen 1.6.0.0) publicly available for others to build from. 2010-01-06T16:39:25 *** r123 has quit IRC 2010-01-06T16:43:25 OCLS-adm: would like to help, but we don't have much to go on. apache error logs? /openils/var/log/osrfsys.log? /openils/var/log/gateway.log? 2010-01-06T16:44:01 did you, by any chance, skip updating opensrf_core.xml with the Evergreen opensrf_core.xml.example? 2010-01-06T16:45:06 (open-ils.auth would need to be listed in the gateway services) 2010-01-06T16:49:13 *** r123 has joined #evergreen 2010-01-06T16:50:01 I will paste the logs in just a second. I was reviewing the install docs. The OpenSRF install and Evergreen installs basically ask you to make the same change -- copy the .example file to be the active .xml file and put the passwords in the correct parts. Unless the docs are wrong and the .example files should come from somewhere in the Evergreen download. 2010-01-06T16:51:11 dbs: maybe we should have Evergreen and bare OpenSRF use differently named config files :) 2010-01-06T16:51:40 OCLS-adm: yes, but the example files are different 2010-01-06T16:52:10 phasefx: geez, I think we had that a long time ago, didn't we? 2010-01-06T16:52:55 I vaguely recall some complexity there.. maybe having to specify multiple config files on a command line 2010-01-06T16:53:21 Which it looks like might be the case... I'm finding .example files under /Open-ILS/examples. So unless these overwrite the existing ones during the 'make' process compiling Evergreen, they may be different. 2010-01-06T16:54:03 but I'm thinking maybe evergreen.xml instead of opensrf.xml and evergreen_core.xml instead of opensrf_core.xml. Though I know at least autogen will look for opensrf_core.xml if nothing is specified 2010-01-06T16:54:58 OCLS-adm: the example files that get placed in /openils/conf/ do get overwritten with different files when you install Evergreen over top of OpenSRF 2010-01-06T16:57:14 I thought they might. I'll break out the log files. Hopefully they will be illuminating... 2010-01-06T16:59:31 OCLS-adm: so to be clear, you do need to base your config files on the example configs from the Evergreen source and not the OpenSRF source 2010-01-06T17:01:37 Which is done by following the same steps after installing Evergreen that you followed after installing OpenSRF (copy example file to xml file and enter correct passwords as registered in ejabberd), right? 2010-01-06T17:01:40 *** r123 has quit IRC 2010-01-06T17:02:09 *** r123 has joined #evergreen 2010-01-06T17:05:29 *** r123 has quit IRC 2010-01-06T17:06:13 *** r123 has joined #evergreen 2010-01-06T17:07:19 OCLS-adm: right 2010-01-06T17:12:00 *** r123 has quit IRC 2010-01-06T17:13:04 *** r123 has joined #evergreen 2010-01-06T17:17:45 That was done. I can go back and compare with the original examples in the package tonight. 2010-01-06T17:20:41 Attempted to paste tails of osrfsys.log and gateway.log -- apparently they were too big. Lots of 401 error messages attaching to Jabber so I'm going to see if I can re-register my users and passwords and make sure they match what's in the .xml files. That'll give me something to do tonight. 2010-01-06T17:21:34 In the meantime, I'm headed to the house. Thanks for the assistance, phasefx and dbs. G'night. 2010-01-06T17:22:58 gnite 2010-01-06T17:25:30 *** OCLS-adm has quit IRC 2010-01-06T17:25:47 *** jenny has left #evergreen 2010-01-06T17:51:57 @later tell djfiander am I reading ITEM_INFORMATION in MsgType.pm correctly in that openncip's SIP 18 implementation doesn't support the AJ field for title identifier? 2010-01-06T17:51:57 dbs: The operation succeeded. 2010-01-06T17:54:14 @later tell djfiander oh I see, those fields are just the ones added in SIP 2, handle_item_information is trying to add both FID_TITLE_ID and FID_ITEM_ID 2010-01-06T17:54:14 dbs: The operation succeeded. 2010-01-06T18:26:09 *** dbs has quit IRC 2010-01-06T18:28:34 *** dbs has joined #evergreen 2010-01-06T18:58:30 the msg64_barcode_type thingy isn't working 2010-01-06T18:59:00 err, msg64_summary_datatype option isn't being recognized; sticking titles in no matter what 2010-01-06T19:09:17 $self->{config} is empty in Patron.pm. That would explain something. 2010-01-06T19:10:55 should be $OpenILS::SIP::config perhaps? hrm 2010-01-06T19:12:25 ahh, OpenILS::SIP::config() 2010-01-06T19:15:33 *** djfiander has joined #Evergreen 2010-01-06T19:17:17 howdy, djfiander 2010-01-06T19:17:24 yo 2010-01-06T19:17:56 The commented out test probably means that I didn't implement that method. Or that I couldn't figure out how to test it. 2010-01-06T19:18:26 I think that I asked berick about it when we were implementing it and he said not to worry 2010-01-06T19:18:33 hmm 2010-01-06T19:18:33 heh 2010-01-06T19:19:11 * dbs is standing in front of the self-check, tweaking code, and testing the results in a highly iterative fashion 2010-01-06T19:22:24 ok, checkout with a renew policy of 'y' should work. 2010-01-06T19:22:55 my SIP code is really just a thin layer. so you need to talk to berick to make sure his ILS interface layer supports it. 2010-01-06T19:23:07 * djfiander passes the buck and bills Equinox for doing so 2010-01-06T19:23:49 see line 546 in Sip/MsgType.pm 2010-01-06T19:23:52 * dbs collaborating with djfiander to drain more 'merican money to Canada 2010-01-06T19:24:10 well, it's not like it's worth anything anymore *sigh* 2010-01-06T19:26:17 heh, the $sc_renew argument is just dropped on the ILS side 2010-01-06T19:27:22 then it's all Bill's fault 2010-01-06T19:27:46 at least I've got that msg64 stuff straightened out 2010-01-06T19:28:50 ok, I was wrong. 2010-01-06T19:28:55 It's Mike's fault. 2010-01-06T19:29:06 theoretically, in OILS::SIP::Transaction::Checkout::do_checkout we should check the sc_renew flag, capture the event if it's an open circ to the same patron, and then fire off a renew 2010-01-06T19:29:09 according to the email we exchanged back in feb of '06. 2010-01-06T19:29:20 exactly right. 2010-01-06T19:29:42 if sc_renew is 'y', then the terminal has decided that this is a renewal. 2010-01-06T19:29:42 I think we also have a problem with the date/time formatting having HH:MM of always 00:00 2010-01-06T19:30:01 what do you mean "we", white man. 2010-01-06T19:30:48 except in the SIP 18 message fields CJ and CM, where instead of leaving them out entirely if there's no active recall or hold pickup date, we drop in '0' :) 2010-01-06T19:31:25 CM 18-char, fixed-length optional field: YYYYMMDDZZZZHHMMSS 2010-01-06T19:31:40 I don't think they mean 0 is an option :) 2010-01-06T19:33:19 my code checks to see if there's a recall date or hold pickup date defined for the item and only sets it in the message if there is. 2010-01-06T19:33:30 see line 1144 2010-01-06T19:33:46 oh fuck me 2010-01-06T19:34:01 no, I only add those fields if they're _not_ defined. 2010-01-06T19:34:05 <- dipshit 2010-01-06T19:34:17 had a fun chat with steve funari from 3m about utf-8 handling 'Okay I see an "e", then (hex CC), then a control character hex 81... so you're passing garbage' 2010-01-06T19:34:26 hah! 2010-01-06T19:34:56 me: "no, that's a decomposed Unicode codepoint 0301 that forms the combining character with the preceding "e" ... that's utf-8" 2010-01-06T19:35:14 that's on the back burner for now anyway 2010-01-06T19:36:05 ok. I will apply the SIP patch that you sent, then I will fix my dumbass mistake in the SIP 18 (item information response) message and check that in 2010-01-06T19:36:13 if I can remember how to use CVS 2010-01-06T19:38:11 djfiander++ 2010-01-06T19:38:37 interesting. When I used Bell DSL, google latitude thought I was somewhere in London. 2010-01-06T19:38:39 okay, and I'm going to head home before I do something really crazy to our production system. luckily it's only SIP 2010-01-06T19:38:56 now that I'm using TekSavvy DSL, google latitude knows _exactly_ where I am. 2010-01-06T19:39:39 teksavvy++ # except I've been having weird dips in bandwidth for the past month or so 2010-01-06T19:39:55 well, bell is throttling them 2010-01-06T19:41:19 djfiander: no, this isn't throttling, this is drops to like, 5kbps or lower for a few minutes, or even death, then back to normal for another half hour 2010-01-06T19:41:28 hunh 2010-01-06T19:42:00 was smooth as silk for 18 months before that. weird. anyway - home! 2010-01-06T19:42:19 *** dbs has quit IRC 2010-01-06T21:19:09 *** brendan_ga has quit IRC 2010-01-06T22:10:02 *** brendan_ga has joined #evergreen 2010-01-06T22:11:30 *** dbs has joined #evergreen 2010-01-06T22:25:53 ok. after three hours, all of my SIP unit tests pass with UTF8 support. 2010-01-06T22:26:34 djfiander++ 2010-01-06T22:26:47 it would be cheaper to teach the entire world to speak english. 2010-01-06T22:27:40 I will check in tomorrow, after I've had time to review all the hacking around I've done and make sure it's ok 2010-01-06T22:31:08 djfiander++ 2010-01-06T22:32:08 *** djfiander has left #Evergreen 2010-01-06T22:52:03 *** mck9 has left #evergreen 2010-01-06T23:29:33 *** pmplett has quit IRC 2010-01-06T23:55:00 *** dbs has quit IRC 2010-01-06T23:59:02 *** dmcmorris has joined #evergreen