| Time |
Nick |
Message |
| 00:33 |
|
tsadok joined #evergreen |
| 08:01 |
|
kworstell-isl joined #evergreen |
| 08:13 |
|
BDorsey joined #evergreen |
| 08:16 |
|
collum joined #evergreen |
| 08:23 |
|
Dyrcona joined #evergreen |
| 08:41 |
|
mmorgan joined #evergreen |
| 08:47 |
|
dguarrac joined #evergreen |
| 08:52 |
|
rfrasur joined #evergreen |
| 09:02 |
|
mantis1 joined #evergreen |
| 10:08 |
Stompro |
jmurray-isl, Re: Content Cafe, they are serving up old images, but only to evergreen libraries because we seem to be the only customers that make use of the XMLPost request method. And they seem to have no way to test request to that service. |
| 10:13 |
Dyrcona |
Stompro: So, someone should open a bug on Lp for us to switch to the REST interface or whatever it is that Koha uses? |
| 10:14 |
Stompro |
Dyrcona, they have a specific method for grabbing just cover art, but we also get author notes and reviews from them. I think the XMLPost method is the only method for grabbing that info. |
| 10:15 |
Dyrcona |
I see... |
| 10:15 |
* Dyrcona |
starts to wonder how B&T stays in business..... |
| 10:15 |
Dyrcona |
Did I say that out loud? Oops! |
| 10:15 |
csharp_ |
Dyrcona++ |
| 10:16 |
csharp_ |
Dyrcona: you used /me, so we all understood that to be internal monologue |
| 10:18 |
Dyrcona |
Yeah, but it is still on the record. |
| 10:18 |
Stompro |
I'm getting really frustrated with them not being able to test their own service. |
| 10:20 |
Dyrcona |
I was just thinking of how I should word this in an email to other CW MARS staff, but I think I'll skip it since no one has opened a ticket, yet. |
| 10:21 |
Dyrcona |
Could we grab images via GET and still get the other information via POST? |
| 10:27 |
Stompro |
Dyrcona, yes, I'm sure that would work, just added complexity. If I remember correctly, it does try and combine different types of content into one request... but I don't think that happens in reality because of how clients request the data. |
| 10:28 |
csharp_ |
most vendors don't really take testing that seriously |
| 10:28 |
csharp_ |
(that could probably provide to all developers everywhere :-)) |
| 10:28 |
* Dyrcona |
thinks we are included in "most vendors." |
| 10:28 |
csharp_ |
s/provide/apply/ |
| 10:28 |
Dyrcona |
csharp_++ |
| 10:29 |
Dyrcona |
Stompro++ for looking into this. |
| 10:36 |
mmorgan |
Stompro++ |
| 10:55 |
Stompro |
Dyrcona, B&T staff assure me that they really only have one master source for the images that all their various endpoints are drawing from... but they make no attempt to explain why we are getting old data also... |
| 10:57 |
Dyrcona |
Cache. |
| 10:58 |
Dyrcona |
There are only 2 hard problems in computer science: naming things, cache invalidation, and off-by-one errors. :) |
| 11:01 |
Stompro |
They asked me what our memcache TTL is... and I'm like, "24 hours, now lets talk about what yours it set to?, it has been serving old data for 5 weeks now??" |
| 11:05 |
Dyrcona |
-1? |
| 11:27 |
jmurray-isl |
Stompro: To test ContentCafe images, I go to the OPAC record and look through the sources for contentcafe. There, I can find something with the following format: https://contentcafe2.btol.com/ContentCafe/jacket.aspx?UserID=<UserID>&Password=<Password>&Return=T&Type=S&Value=<ISBN-Number> |
| 11:27 |
jmurray-isl |
Type equates to S, M, or L. |
| 11:29 |
jmurray-isl |
I mean, it is a bit concerning that just anyone can view our ContentCafe credentials this way... |
| 11:31 |
Bmagic |
jmurray-isl: I had the same thought whilst looking through this code. Syndetics works the same way. The "authentication" is simply our ID string embedded in the query string. If they charged based on number of requests, then I would be a bit more concerned :) |
| 11:36 |
Stompro |
jmurray-isl, our Evergreen setup doesn't expose the username and pw, I did notice that Evergreen Indiana does have two different sets of cover art links. The problem is that the jacket.aspx method is returning fresh data, but the XMLpost method that evergreen uses is serving old data. let me grab an example. |
| 11:37 |
Stompro |
Compare https://evergreen.lib.in.us/opac/extras/ac/jacket/medium/9781608095377 and https://evergreen.lib.in.us/eg/opac/record/22903128 |
| 11:38 |
Stompro |
The cover art in the "Awards, Reviews and Suggested Reads" section uses the jacket.aspx method, and is correct. |
| 11:40 |
jmurray-isl |
That's very interesting, indeed, and explains a few things. Thank you for pointing that out. |
| 11:42 |
Stompro |
The /opac/extras/ac/ method has some nice features, like accepting a bibid number instead of ISBN, it then grabs all ISBNs and UPCS and asks B&T for all cover art for all the identifiers, and returns the first one. |
| 11:45 |
Stompro |
It also caches the cover art locally in the evergreen memcache service. Which I have mixed feelings about. It seems like it is mainly saving the vendors bandwidth, while putting more load on the evergreen servers. |
| 11:47 |
jeff |
there are other benefits, but there are also some downsides to the data being in the same memcached instance that we're using/abusing for auth sessions, for example. |
| 11:55 |
Dyrcona |
jmurray-isl: I think your use of jasket.aspx if a local change. I don't find it anywhere in the Evergreen code, unless it's added by Novelist or another JavaScript add-on. |
| 11:57 |
Dyrcona |
The caching is also meant to speed up record loading. It's not just about conserving bandwidth. It takes time to make the requests and retrieve the data. Think about doing that for 10 items at a time each for a few hundred simultaneous users. |
| 12:00 |
jmurray-isl |
Dyrcona: Thanks for pointing that out. I'm definitely still in the process of learning, here. |
| 12:01 |
* Dyrcona |
just noticed the typo: jasket.... :( |
| 12:02 |
Dyrcona |
Don't blow a jasket, now... |
| 12:02 |
|
jihpringle joined #evergreen |
| 12:02 |
|
Christineb joined #evergreen |
| 12:05 |
mantis1 |
lol |
| 12:23 |
csharp_ |
@band add Blown Jasket |
| 12:23 |
pinesol |
csharp_: Band 'Blown Jasket' added to list |
| 12:23 |
csharp_ |
@band |
| 12:23 |
pinesol |
csharp_: Drive By kmlussier |
| 12:24 |
csharp_ |
@who wants to go see [band] this weekend with [someone]? |
| 12:24 |
pinesol |
troy wants to go see Max, Spare the Children this weekend with csharp. |
| 12:24 |
csharp_ |
troy: I'm game |
| 12:25 |
troy |
impromptu trip! |
| 12:25 |
Bmagic |
kmlussier++ # getting me excited for the conference with web posting |
| 12:26 |
csharp_ |
@who is a cookie pusher? |
| 12:26 |
pinesol |
abneiman is a cookie pusher. |
| 12:48 |
Bmagic |
when I run the eg_db_config - it determines that I'm on PG 10, and executes 000.english.pg10.fts-config.sql (and many other things) - that file, has one line: 000.english.pg94.fts-config.sql |
| 12:49 |
Bmagic |
I'm getting an error, complaining about that line. I'm confused what would cause that line to be "wrong" sometimes and not others. Environemnt? |
| 12:50 |
Dyrcona |
Bmagic: Is 000.english.pg10.fts-config.sql a plain file? It is supposed to be a link. |
| 12:50 |
Bmagic |
ah! there we go. OK, so it's checked out on Windows and passed into a container |
| 12:52 |
Bmagic |
so now I'm wondering if links are just plain broken when using git for Windows |
| 12:52 |
Dyrcona |
That might do it. I've seen links converted to files with the path to the link inside depending on how they are copied. |
| 12:53 |
Dyrcona |
Depending on your file system, that's all links are: files with the path to the target inside. They may have additional metadata. |
| 12:53 |
Dyrcona |
Windows lnk files are a different beast. |
| 12:53 |
Bmagic |
https://stackoverflow.com/questions/5917249/git-symbolic-links-in-windows/59761201#59761201 |
| 12:54 |
Bmagic |
so it seems that I need to set some git settings ahead of the git clone command |
| 12:54 |
Dyrcona |
Yeah, looks like it. |
| 12:55 |
Bmagic |
things get really weird when I bind mount my Windows cloned repo, into a docker container on Windows.... This might* be impossible |
| 12:55 |
Dyrcona |
I'd assume its possible. It's probably difficult to get things working properly. |
| 13:00 |
Dyrcona |
Reading the Stack Overflow that Bmagic linked, I'm struck by first sentence: "Our developers use a mix of Windows and Unix-based OSes." |
| 13:00 |
|
collum joined #evergreen |
| 13:00 |
Dyrcona |
I feel like saying, "Don't do that." :) I've gotten answers of a similar useless quality over the years online. |
| 13:05 |
Dyrcona |
Of course, one could also argue that putting links in git is the actual mistake. |
| 13:06 |
Bmagic |
npm install makes links |
| 13:07 |
Bmagic |
Looking around the repo, there are very few links. Which is nice. It seems like I might be able to take care of the few that I need fixed and call it a day |
| 13:07 |
Dyrcona |
Bmagic: That's not really a response to "putting links in git is a mistake." I'm also just speculating. |
| 13:07 |
Bmagic |
I used this command: find -type l|grep -v modules |
| 13:08 |
Dyrcona |
We don't put the npm modules in our git repo though, do we? |
| 13:08 |
Dyrcona |
Yeah, we don't. |
| 13:08 |
Bmagic |
nope, but in my particular folder tree, I had already ran npm install in various folders |
| 13:09 |
Bmagic |
which gave me false positives, so I grepped them out of the results of the find command |
| 13:09 |
Dyrcona |
OIC: It complicates your situation and what I suggested to you in private chat won't work. |
| 13:09 |
Dyrcona |
Heh. Then I read your follow up and that's what you're going to do. :) |
| 13:10 |
Dyrcona |
That mklink script on the stack overflow is clever, but I suggested adding a post check out script to replace the links with the contents of the original files. <- for the logs. |
| 13:10 |
Bmagic |
well, here's what I've ended up having to do: at Docker runtime, I'm rsyncing the provided Windows cloned repo into the linux file system, and installing Evergreen, then symlinking the angular folder and angularJS folder from /openils....... -> appropriate Windows repo folders |
| 13:12 |
Dyrcona |
Yeah. You can have rsync convert links to copies of the files, or maybe hard links with work... |
| 13:12 |
Bmagic |
yep |
| 13:12 |
Dyrcona |
The big issue is that Windows and Linux don't agree on what links look like, and when I looked into it, Windows links can look different depending on Windows version. |
| 13:13 |
Bmagic |
yeah, it's hairy, which is why I'm going the route of converting them to regular files |
| 13:14 |
Dyrcona |
We have 10 links in a checkout of the master branch. The rel_X_Y_Z branches have 1 less because the README is replaced by the contents of the file it points to. |
| 13:14 |
Bmagic |
npm install creating links is a new twist. I'll have to figure out how to deal with that. |
| 13:15 |
Dyrcona |
I wonder if you could add a post install script to the npm configuration to rsync the links into files? I haven't really looked into how that part of npm works. I know you can do a lot of tricks with it, though. |
| 13:16 |
Bmagic |
my current plan is to run it on the linux FS, then rsync over to the Windows folder mount, with switches to have rsync create regular files |
| 13:17 |
Bmagic |
-L I believe |
| 13:17 |
Dyrcona |
That sound like it would work. |
| 13:19 |
Dyrcona |
Now, I'm back to a variation of the Stack Overflow question: I want to run Docker on Windows with a Linux image that I want to have access to a git repository on the Windows filesystem.... "Don't do that.... Make your life easier, and just use Linux." :P |
| 13:19 |
Dyrcona |
Anyway, Bmagic++ I'm sure you'll figure it out. |
| 13:20 |
Bmagic |
This isn't for me, it's for you (the Evergreen community) - I'm trying to lower the bar of Evergreen development. Allowing for the developer to use either OS |
| 13:20 |
Dyrcona |
I'd still recommend not doing that. Just using Linux is easier. :) |
| 13:21 |
Bmagic |
it's only easier because we've developed it that way :) |
| 13:21 |
Dyrcona |
But, in all seriousness, I think it is cool what you're trying to do, i.e. lower the barrier for new developers. |
| 13:21 |
Bmagic |
ty! |
| 13:22 |
Dyrcona |
Well, we could replace 10 links with files and fix our end of the biggest issue. I'd say to not even bother copying the npm modules back to Windows. |
| 13:23 |
Bmagic |
I've got it semi documented and the early version of the container (doesn't work on Windows yet) here: https://hub.docker.com/repository/docker/mobiusoffice/evergreen-ils/general SEE "DEV container - for hacking Evergreen" |
| 13:23 |
Dyrcona |
Next thing, you'll be trying to get OpenSRF and Evergreen to install and run on Windows..... :) |
| 13:24 |
Dyrcona |
Bmagic: That docker hub linked asked me for a login. |
| 13:24 |
Bmagic |
oh: https://hub.docker.com/r/mobiusoffice/evergreen-ils |
| 13:26 |
Dyrcona |
Yeahp. I have been meaning to try Docker out on a spare server as well as to give the Ansible installation process another try. |
| 13:26 |
Dyrcona |
I spend too much time chatting in IRC, though. |
| 13:27 |
Bmagic |
I'm glad you do! |
| 13:28 |
Dyrcona |
:) |
| 15:12 |
|
mantis1 left #evergreen |
| 17:04 |
|
mmorgan left #evergreen |
| 17:46 |
|
jihpringle joined #evergreen |
| 19:17 |
|
jihpringle joined #evergreen |
| 20:06 |
|
kmlussier joined #evergreen |
| 20:07 |
* kmlussier |
now contemplates getting a "cookie pusher" t-shirt. |
