2008-03-14T00:04:57 *** greg-g has quit IRC 2008-03-14T00:36:14 *** jeff has joined #openils-evergreen 2008-03-14T00:46:52 *** agJohn has quit IRC 2008-03-14T02:22:57 *** jeff has quit IRC 2008-03-14T02:22:57 *** tristanbob_ has quit IRC 2008-03-14T02:22:57 *** lisppaste6 has quit IRC 2008-03-14T02:23:22 *** jeff has joined #openils-evergreen 2008-03-14T02:23:22 *** lisppaste6 has joined #openils-evergreen 2008-03-14T02:29:24 *** atheos has quit IRC 2008-03-14T02:29:24 *** eeevil has quit IRC 2008-03-14T02:29:31 *** eeevil has joined #openils-evergreen 2008-03-14T02:31:25 *** atheos has joined #openils-evergreen 2008-03-14T02:31:47 *** Mark__T has joined #openils-evergreen 2008-03-14T02:38:26 *** tristanbob__ has joined #OpenILS-Evergreen 2008-03-14T03:04:06 *** phase_bb has quit IRC 2008-03-14T03:45:29 *** jmellis has joined #openils-evergreen 2008-03-14T03:47:42 *** jmelli1 has quit IRC 2008-03-14T04:46:05 *** jeff has quit IRC 2008-03-14T08:18:31 *** greg-g has joined #openils-evergreen 2008-03-14T08:56:34 *** Karen_ has joined #OpenILS-Evergreen 2008-03-14T09:02:25 *** pmurray_away is now known as pmurray 2008-03-14T09:14:51 *** jeff has joined #openils-evergreen 2008-03-14T09:49:44 *** JMCraig has joined #openils-evergreen 2008-03-14T09:49:46 *** JMCraig is now known as agJohn 2008-03-14T10:08:03 *** jmellis has left #openils-evergreen 2008-03-14T10:08:25 *** jmellis has joined #openils-evergreen 2008-03-14T10:14:01 *** phase_bb has joined #openils-evergreen 2008-03-14T10:47:33 *** pmurray is now known as pmurray_away 2008-03-14T10:52:18 *** Mark__T has left #openils-evergreen 2008-03-14T11:04:46 ok, any recommendations on how to let opensrf's makefile know where memcache.h is? 2008-03-14T11:06:21 rsinger: if it's not in a well-known place, you can do something along the lines of: 2008-03-14T11:06:25 # CFLAGS="-I /blah" make 2008-03-14T11:06:36 pass it in explicitly 2008-03-14T11:06:42 berick: yeah, that will do 2008-03-14T11:06:49 berick: it's in /opt/local/include 2008-03-14T11:07:25 did you have to manually install memcache? 2008-03-14T11:07:38 well, i guess it's libmemcache 2008-03-14T11:07:45 via macports 2008-03-14T11:07:51 ah, ok 2008-03-14T11:10:01 ld: unknown option: -rpath=/openils/lib 2008-03-14T11:10:15 maybe i should just try this on a vm 2008-03-14T11:10:55 rsinger, I wasted many hours trying to accomplish the same thing 2008-03-14T11:11:03 atheos: :) 2008-03-14T11:11:11 atheos: on a mac? 2008-03-14T11:11:16 yes 2008-03-14T11:11:18 yeah 2008-03-14T11:11:19 on a g4 2008-03-14T11:11:34 hey, atheos 2008-03-14T11:11:34 well, i'm not even trying it on that 2008-03-14T11:11:38 vmware on my mac pro does the trick 2008-03-14T11:11:53 but it does bring back memories of trying to compile things in nextstep 2008-03-14T11:11:59 well, you can get all the dependencies going just fine 2008-03-14T11:12:14 I say "just fine" as if it were simple 2008-03-14T11:12:42 fwiw, -rpath is not required. you can accomplish the same thing with LD_LIBRARY_PATH 2008-03-14T11:12:55 my problem is that that's not exactly going to quiet questions about the suitability of opensrf for jangle 2008-03-14T11:13:43 rsinger: are you using gcc? 2008-03-14T11:14:04 * rsinger shrugs? 2008-03-14T11:14:33 oh, i thought you had to explicitly install a compiler on mac 2008-03-14T11:14:41 you do, it's in the developer pack 2008-03-14T11:16:02 ok, Xcode uses gcc 2008-03-14T11:17:05 if someone can get evergreen working natively on OSX, I'll buy them a macbook ! 2008-03-14T11:17:30 mmmmm, tempting 2008-03-14T11:18:26 anyone need shell access ? :) 2008-03-14T11:18:34 heh 2008-03-14T11:18:38 * phasefx wonders if his wife will let him borrow her mac 2008-03-14T11:24:41 yeah, i have xcode installed 2008-03-14T11:27:31 ha, I just found my notes from my attempt at installing opensrf on osx. not sure how useful, but anyone want them? 2008-03-14T11:27:39 rsinger: i would try removing the -rpath setting in src/Makfile 2008-03-14T11:30:46 currently reads: export LDFLAGS += -Wl,-rpath=$(LIBDIR) -L $(TMPDIR) -L . 2008-03-14T11:31:03 so, should read: export LDFLAGS += -Wl -L $(TMPDIR) -L . 2008-03-14T11:31:04 ? 2008-03-14T11:31:16 clear 2008-03-14T11:31:19 oops 2008-03-14T11:32:41 looks right 2008-03-14T11:33:45 may not need the "-Wl", either 2008-03-14T11:34:34 yeah, -Wl tells gcc to pass the -rpath flag to the linker.. so you can drop the -Wl as well 2008-03-14T11:34:47 s/can/should/ 2008-03-14T11:34:56 ld: in /tmp/ilstemp/opensrf, can't map file, errno=22 2008-03-14T11:35:01 ok 2008-03-14T11:35:22 atheos pasted "Evergreen on OSX, good luck" at http://paste.lisp.org/display/57364 2008-03-14T11:43:12 *** Karen_ has left #OpenILS-Evergreen 2008-03-14T12:07:25 miker_: when we first talked about jangle, you raised the question of whether or not it should support APP 2008-03-14T12:07:50 and the more i think about this, the more i like the idea 2008-03-14T12:08:10 but i need a more nuanced perspective than my crude monkey brain 2008-03-14T12:24:51 ok, i'll just keep talking 2008-03-14T12:25:22 and someone can try to stop me when they're tired of my crazy talk 2008-03-14T12:25:50 rsinger: miker_ is away from irc for the moment. please, keep talking :) 2008-03-14T12:26:02 APP= Atom publishing protocol? 2008-03-14T12:26:18 so you'd have client -> APP -> Jangle core -> JSON (let's say) -> connector -> ILS (or other system) 2008-03-14T12:26:21 berick: yeah 2008-03-14T12:26:56 jangle would then basically be deciding how to model the backend data to fit into an atomic world 2008-03-14T12:27:28 and brokering requests to their appropriate connectors 2008-03-14T12:27:41 s/deciding/defining/ 2008-03-14T12:29:14 I see, and APP would be the de facto access mechanism for clients talking to Jangle? 2008-03-14T12:29:20 right 2008-03-14T12:29:39 so we're not inventing some new way to do this that only we know how to use 2008-03-14T12:29:51 indeed 2008-03-14T12:29:52 GET /jangle/Actor/12345 2008-03-14T12:31:06 jangle sends the request to the appropriate connector, the spec defines what data elements the connector needs to send back, jangle maps that into the defined atom collection document 2008-03-14T12:32:23 seems fairly tidy 2008-03-14T12:34:52 and more ubiquitous 2008-03-14T12:35:04 and possibly compatible with gdata 2008-03-14T12:47:51 jangle effectively becomes a spec to model library services for app 2008-03-14T12:48:10 well, two things 2008-03-14T12:48:45 the aforementioned, plus a framework for actually accomplishing said goal 2008-03-14T13:15:00 rsinger: a couple things ... that's fine for data access, but for functional parts of, say, the DLF paper (placing holds, etc) I don't think it's a good fit ... IMO, xml-rpc covers the CRUD and functional portions better 2008-03-14T13:17:39 however, for CRUD, APP would be great, and there are plenty of perl modules (for a mod_perl interface) and probably python modules that implement ATOM and would easily provide that layer 2008-03-14T13:18:11 just client->ATOM->mod_{something}->opensrf (jangle core)->connector 2008-03-14T13:21:59 rsinger: does that makes sense? I realize it's all rambly 2008-03-14T14:23:29 *** sylvar has quit IRC 2008-03-14T14:24:51 *** sylvar has joined #openils-evergreen 2008-03-14T14:43:45 miker_: why don't you think it'd work for holds? 2008-03-14T14:43:53 recalls, etc. etc. 2008-03-14T14:45:14 rsinger: I have a mental distinction between CRUD (simple) and things that involve a bunch of biz logic (even if the output is ok/fail) 2008-03-14T14:45:53 miker_: ok, go on 2008-03-14T14:47:46 miker_: i mean, what does that mean to the client? 2008-03-14T14:52:13 *** atheos has quit IRC 2008-03-14T14:52:34 well, in the client, an xml-rcp call or a url get is about the same ... you have to have a library to make the call and parse the results either way 2008-03-14T14:52:35 miker_: i think my point here is "i'm not arguing, i'm seeking clarity" 2008-03-14T14:53:29 but, conceptually, making a "perform this fuction" call is different from "update this datum" call ... the latter is a special case of the former 2008-03-14T14:54:00 but "place a hold on this title" isn't the same as "updated this datum" ... in my head, anyway 2008-03-14T14:54:06 sure it is 2008-03-14T14:54:13 Create hold 2008-03-14T14:54:53 i mean, i'm being simplistic 2008-03-14T14:55:22 but, i'm not sure why POSTing a new Hold resource would be much different 2008-03-14T14:55:25 the distinction I see is that the output is (to a much larger extent than with, say, Create Item Record) system generated ... 2008-03-14T14:56:15 but maybe I'm crazy? 2008-03-14T14:56:22 define system generated? 2008-03-14T14:56:41 you mean, dependent on the backend system? 2008-03-14T14:57:01 and whatever value that system might cough back (or not) 2008-03-14T14:58:43 I think my problem is that I'm thinking of it in terms of what the ILS does, not an absolute lowest-common-denominator thing 2008-03-14T14:59:04 so you have a patron id and (in general) a title record id 2008-03-14T14:59:09 and you say "gimme that" 2008-03-14T14:59:34 and, in the simplest sense, you're tossed in a queue for an item on the record 2008-03-14T15:00:26 right 2008-03-14T15:00:36 but (taking evergreen as an example) there are a couple dozen fields on the hold request object, most filled in by the system based on configured settings and locally defined process 2008-03-14T15:00:51 right 2008-03-14T15:01:49 does the client interact with the server for this? 2008-03-14T15:02:01 so, if all we're looking to expose is a "gimme that" interface for POST, and maybe a "freeze/thaw/cancel this" PUT interface (or maybe cancel is a DELETE) then I can see APP working 2008-03-14T15:02:36 and maybe that's the right thing 2008-03-14T15:02:48 so, ok, what would be the use case for exposing more complexity there? 2008-03-14T15:04:03 well, if we're talking about APP being the Blessed(tm) interface, then nothing, probably ... nothing that a more advanced process wouldn't be fine using xml-rpc or a native interface for 2008-03-14T15:04:51 but if APP is the "only" interface, then I could maybe think of some 2008-03-14T15:05:26 put another way: 2008-03-14T15:06:57 I'm completely down with "the simplest thing that could possibly work" and if that means APP, then that's great ... but I tend to shy away from using protocols that require layering lots of client side logic on top in order to do more complex things. does that make sense? 2008-03-14T15:07:18 absolutely 2008-03-14T15:07:33 APP is so dead simple (good for most things) that it makes the few more complicated things much harder 2008-03-14T15:07:53 well, that's why i'm trying to isolate those harder things 2008-03-14T15:08:00 right 2008-03-14T15:08:10 because it's possible they may be better served with their own spec 2008-03-14T15:08:47 with your ILL concept -- what are the data points you would absolutely need? 2008-03-14T15:08:54 like, nonstarter without? 2008-03-14T15:09:04 the way I would approach it is: does the common subset map well to crud? then APP (or the like) is a good fit 2008-03-14T15:09:27 miker_: yeah, that's the question i'm trying to answer 2008-03-14T15:10:28 take the DLF ILS API recommendation 2008-03-14T15:10:40 let's just use that as a functional req. document 2008-03-14T15:10:46 (for s&g) 2008-03-14T15:11:04 i'm not sure there's anything there that's not CRUD 2008-03-14T15:12:03 FilfILLment(tm)? ;) ... I'd need patron id (barcode probably), patron type, patron home institution, and a list of relevant item id (barcode), item type, item location, item status 2008-03-14T15:12:21 the ugly part would be defining the explicit values that are agreed upon 2008-03-14T15:12:47 aah, well, I consider that the problem of the client, other than item status 2008-03-14T15:13:00 you think? 2008-03-14T15:13:11 that seems very Z39.50 2008-03-14T15:13:26 let's take status information 2008-03-14T15:14:11 well, status info can be normalized to "available", "checked out (will become available)" and "will not be available" 2008-03-14T15:14:12 why can't we agree on, "available", "not available", "will be available on d" 2008-03-14T15:14:17 haha 2008-03-14T15:14:19 we can 2008-03-14T15:14:19 yeah 2008-03-14T15:14:21 :) 2008-03-14T15:14:33 and we can map an actor to, say, vcard 2008-03-14T15:15:07 that's what I mean. item status is something that should be normalized, but things like "patron type" not so much 2008-03-14T15:15:22 yeah, i have no problem with that 2008-03-14T15:15:22 nor "item type" ... unless we use the MARC item type relators 2008-03-14T15:15:39 yeah... but we might not have all marc data 2008-03-14T15:16:22 I wonder if there's something that isn't covered by marc item type relators, though 2008-03-14T15:16:38 but, again -- i think we are in agreement that those are client problems 2008-03-14T15:16:41 I mean, we map to that as the authoritative list, not that that's what the data has to contain 2008-03-14T15:16:45 right 2008-03-14T15:17:24 so, with APP (again, pointing back to the DLF docs), we can easily do the Harvest functionality 2008-03-14T15:17:40 Search 2008-03-14T15:19:43 except maybe Scan 2008-03-14T15:20:08 well, i guess scan is possible 2008-03-14T15:20:25 (nobody's going to understand it, though) 2008-03-14T15:21:23 and I don't really see any patron functionality that couldn't be covered 2008-03-14T15:21:52 not that the dlf api should be the ultimate goal, of course 2008-03-14T15:22:37 I need to stop working and just read that end to end ... 2008-03-14T15:24:45 it's actually really short 2008-03-14T15:25:10 since they define every "method invocation", there's a lot of repetition 2008-03-14T15:26:25 and now I can't find it 2008-03-14T15:27:25 found it ... I think 2008-03-14T15:27:39 is it not final? 2008-03-14T15:27:42 https://project.library.upenn.edu/confluence/display/ilsapi/Home 2008-03-14T15:27:51 no 2008-03-14T15:27:56 why did I think it was final... 2008-03-14T15:28:57 hope springing eternal, i suppose 2008-03-14T15:33:35 ok, i'm going to pitch this idea to the jangle list 2008-03-14T15:34:11 if nothing else, in the effort to finally gain some traction 2008-03-14T15:34:31 is that jangle-discuss? 2008-03-14T15:34:35 yeah 2008-03-14T15:35:22 i think the biggest hurdle right now is trying to figure out what we're doing -- this at least gives us some sense of "goal" 2008-03-14T15:35:36 without having to construct everything from the ground up 2008-03-14T16:16:02 ok, that puts something out there for us to at least pull apart or build upon 2008-03-14T16:23:32 *** sylvar__ has joined #openils-evergreen 2008-03-14T16:23:32 *** sylvar has quit IRC 2008-03-14T16:23:34 *** sylvar__ is now known as sylvar 2008-03-14T18:14:21 *** jmellis has left #openils-evergreen 2008-03-14T20:16:45 *** gmcharlt has quit IRC 2008-03-14T20:53:08 *** greg-g has quit IRC 2008-03-14T20:56:46 *** greg-g has joined #openils-evergreen 2008-03-14T21:55:36 *** greg-g has quit IRC 2008-03-14T21:59:06 *** greg-g has joined #openils-evergreen 2008-03-14T22:46:05 *** sylvar has quit IRC