Log of the #duraspace-ff channel on chat.freenode.net

Using timezone: Eastern Standard Time
* jcoyne leaves00:53
* ksclarke leaves01:23
<pivotal-bot>Esme Cowles started "fcrepo-jms should send post-translation identifiers, not the raw JCR paths" https://www.pivotaltracker.com/story/show/7226279008:03
* dwilcox joins08:19
* jcoyne joins08:34
* jcoyne leaves09:02
* dwilcox leaves
* ksclarke joins09:12
* dwilcox joins09:14
<pivotal-bot>Esme Cowles added comment: "Given the indirection involved in the event system, I don't see how the JMS event generation is going to be ..." https://www.pivotaltracker.com/story/show/7226279009:37
* scossu joins10:04
<pivotal-bot>Chris Beer added comment: "+1" https://www.pivotaltracker.com/story/show/7226279010:11
* jcoyne joins10:24
* dwilcox leaves10:25
* dwilcox joins10:29
* nikhiltri joins10:50
* dwilcox leaves10:51
* dwilcox joins11:05
* dwilcox leaves11:08
* dwilcox joins
* dwilcox leaves11:12
* dwilcox joins11:15
* dwilcox leaves11:34
<pivotal-bot>Esme Cowles added comment: "I had been running two sets of tests on the UCSD VMs: large file testing on two VMs, and F3/F4 CRUD testing ..." https://www.pivotaltracker.com/story/show/7072460411:48
Esme Cowles finished "Revisit Holiday-Release tests" https://www.pivotaltracker.com/story/show/7072460411:49
* longshou joins12:06
* terrellt leaves12:15
* terrell_t joins12:16
<cbeer>ksclarke: with your IIIF/fcrepo4 proposal, do you have an idea for how to get the info.json back out using the prescribed URI syntax (..../info.json) instead of via fcr:content?12:22
<ksclarke>cbeer: I was imaging a iiif restful endpoint (separate from the standard rest api)12:26
<jcoyne>ksclarke: It might be nice to just have that be a separate component. I can imagine wanting my IIIF server to have a nice big cache, that I don't care about12:28
<ksclarke>cbeer: similar to how webdav or cmmis are different
<jcoyne>which is different from my Repository data, which I really care about.
<cbeer>jcoyne: https://wiki.duraspace.org/pages/viewpage.action?pageId=5796679312:29
<ksclarke>jcoyne: the external image server would definitely be a separate component
<jcoyne>The part that scares me is "support the http://iiif.io/ in Fedora 4"12:30
<ksclarke>jcoyne: in what way?
because it's rapidly changing?
<jcoyne>The fact that it's *IN* the repository.12:31
* github-ff joins
[fcrepo4] escowles created jms-msg-format (+1 new commit): http://git.io/9uD9Vg
fcrepo4/jms-msg-format 5a4248c Esmé Cowles: Adding list of properties and a System-property-configurable baseURL to JMS events
* github-ff leaves
<jcoyne>I really like the repository to have the single responsibility of storing my data, not operating on it.12:32
<ksclarke>jcoyne: yeah, understandable... I've been thinking about them as separate services before this too
* github-ff joins
[fcrepo4] escowles opened pull request #400: Adding list of properties and a System-property-configurable baseURL to JMS events (master...jms-msg-format) http://git.io/RrX0xA
* github-ff leaves
<ksclarke>and maybe it's not desired/desirable to have the repo serve the info.json files...
<jcoyne>If I change how I operate on the data, I don't want to have to restart the repository.
Just my perspective.12:33
<ksclarke>what do you mean how I operate on the data? change to a non-iiif image server?
<pivotal-bot>Esme Cowles added "Update JMS indexer to use JMS message baseURL" https://www.pivotaltracker.com/story/show/7235174012:34
<jcoyne>I'm speaking more generally now. Say I want to change to version 2 of IIIF. Do I have to have repository downtime to do that upgrade?
<pivotal-bot>Esme Cowles added "Get baseURL for JMS events from JAX-RS instead of requiring it be configured separately" https://www.pivotaltracker.com/story/show/7235191812:36
<ksclarke>I'm not as familiar with spring, modeshape, etc. and whether things can be configured without bringing the system down12:37
<pivotal-bot>Esme Cowles added comment: "I've added a list of added/updated properties and a baseURL (configurable with System property) to the JMS m..." https://www.pivotaltracker.com/story/show/7226279012:38
Esme Cowles finished "fcrepo-jms should send post-translation identifiers, not the raw JCR paths" https://www.pivotaltracker.com/story/show/72262790
<ksclarke>jcoynes: but a valid concern, true12:39
<cbeer>escowles: i'm late with this, but have you seen http://www.day.com/maven/jsr170/javadocs/jcr-2.0/javax/jcr/observation/ObservationManager.html#setUserData(java.lang.String)?12:41
i wonder if we could use that to smuggle the base URI from the REST API to the backend12:42
<escowles>cbeer: maybe -- with that interface, do we get to set just a single value?12:44
<ksclarke>jcoynes: seems with the separate rest endpoint, it would definitely be an add-on... not something that's a part of fcrepo4 proper (so no requirement to have it in any given repo instance)12:46
* travis-ci joins12:47
[travis-ci] fcrepo4/fcrepo4#2096 (jms-msg-format - 5a4248c : Esmé Cowles): The build passed.
[travis-ci] Change view : https://github.com/fcrepo4/fcrepo4/commit/5a4248c7b61f
[travis-ci] Build details : http://travis-ci.org/fcrepo4/fcrepo4/builds/26399775
* travis-ci leaves
<jcoyne>So, then what is the difference between "IIIF in FC4" and "An IIIF server that can pull content from FC4"12:48
* dwilcox joins
<ksclarke>I think whether fcrepo4 serves the info.json
<pivotal-bot>Esme Cowles added comment: "This may be a mechanism for passing the baseURL from JAX-RS level down to where the event system can find it..." https://www.pivotaltracker.com/story/show/7235191812:49
* edInCo joins
<ksclarke>or whether the external image server is just pulling jp2s/tiffs from the repo
<jcoyne>That just seems like a lot of complication for something that is trivial to do.
<ksclarke>serve the info.json you mean?
<ksclarke>it may be more of a conceptual accomplishment, for those who want their repo to speak iiif12:50
<jcoyne>Trivial might be too strong, lets say "a problem that's already been solved".
ksclarke: I want a pony.12:51
<cbeer>escowles: yeah, we only get one value. but we could smuggle a serialized object, i guess
<ksclarke>in the same way, it shouldn't be a huge undertaking to make it happen12:52
so if it's low hanging fruit and some in the community want it...
*poof* a pony
and perhaps another benefit (which is very fuzzy in the proposal) is having an image server which shares access control with the repo; that's outside the scope of iiif but in the realm of "how do we make fcrepo4 support iiif"12:53
<pivotal-bot>Esme Cowles added comment: "I rebased this branch on master, thinking some of the federated filesystem changes might resolve this, but n..." https://www.pivotaltracker.com/story/show/71903492
* dwilcox leaves12:55
<escowles>cbeer: right, with JSON or some other serialization we could have structured data, as long as we were careful to check the state and didn't overwrite existing data
* ksclarke adds jcoyne's question about downtime as a result of iiif changes to the list of open questions on that page12:56
<jcoyne>I think I'd much rather see an IIIF image server that is FC4 aware, rather than IIIF built into FC412:58
* nikhiltri leaves
* dwilcox joins
<ksclarke>so what does that mean to you? being able to access tifs and jp2s, etc., from the repo within the image server?
<jcoyne>ksclarke: something that takes the identifier from an IIIF url, maps it to an object stored in FC4 and gives me the derivatives I want.13:01
Ideally it's a war file that only requires the credentials for the FC4 server it hooks up to.
I can deploy it in the same JVM as FC4, or I can deploy it on a different machine entirely
It should be able to handle a variety of image formats, TIFF, JP2, Jpeg, etc. (because I really don't want to store derivatives in my repository, just originals)13:03
<ksclarke>I have a djatoka fork that pretty much does that... it takes an identifier (which could be pulled from an IIIF request - this it doesn't do yet) and matches it against a URL pattern (which could be how to retrieve the jp2 from a fcrepo4 datastream) and then generates all the derivatives from the jp2 - it would also work pulling the tiff from the repo
and that's the direction I was originally thinking too :-)13:04
<jcoyne>That sounds great then.
close the ticket.
<ksclarke>heh, so what triggers the taking of the identifier? the first request for that image?
<jcoyne>Would you mind rebranding it because "ksclarke's fork of Djatoka" is just hard to sell.
<ksclarke>a batch job?
<bljenkins>Project fcrepo4 build #1929: UNSTABLE in 34 min: http://ci.fcrepo.org/jenkins/job/fcrepo4/1929/
<jcoyne>I dunno, maybe, or maybe listening to JMS requests?
<ksclarke>ideally, I'd like to pull ahead of time and pre-generate all the tiles (something else it can do); rather than have to generate a ton of tiles on user request
<jcoyne>ksclarke: but IIIF doesn't constrain derivatives to just tiles, does it?13:06
<ksclarke>so it listens to fcrepo's jms queue?
<jcoyne>I can get any arbitrary transformation, right/
<ksclarke>no, it doesn't... those have to be live... but things like openseadragon tiles can be pre-generated
<jcoyne>ksclarke; yeah
ksclarke: depending on how much cache you have available.13:07
<cbeer>escowles: https://github.com/fcrepo4/fcrepo4/pull/400/files#r1323874713:08
* ksclarke creates a ticket in his project for the jms idea ;-)
<jcoyne>So, it should also have a bounded LRU cache too
<ksclarke>jcoyne: so I take the approach that I want to cache all the tiles that constant like openseadragon, but not all the randomly generated ones13:09
so the permanent cache can get big :-)
<jcoyne>And I might want to be able to write my own caching strategy.13:10
<ksclarke>yeah, would be nice to have something for thumbnails, standard sized images, etc.
right now mine is a "prune from the cache" things that don't fit a pattern, rather than a more sophisticated approach13:11
so, does it match this type of pattern I want to keep? no, delete it periodically
* ksclarke has gone way off track of iiif and fedora integration13:12
* jcoyne leaves13:14
* scossu leaves14:37
* scossu joins14:48
* terrellt leaves14:59
* gregjansen joins15:17
* github-ff joins15:20
[fcrepo4] escowles force-pushed sparql-bad-request from a90de16 to e0f9b33: http://git.io/vk9nwQ
fcrepo4/sparql-bad-request 35c9b9f Esmé Cowles: Handling errors with sparql update queries that reference non-existent resources, fixing empty query error handling, adding ITs
fcrepo4/sparql-bad-request e0f9b33 Esmé Cowles: Fixing ITs
* github-ff leaves
<pivotal-bot>Esme Cowles added comment: "The ITs were failing because they were creating the SPARQL queries in entity objects, but not adding them to..." https://www.pivotaltracker.com/story/show/7190349215:21
Esme Cowles finished "A POST/PUT with an object (that is a fedora subject) that doesn't exist should not raise a 404" https://www.pivotaltracker.com/story/show/71903492
Esme Cowles started "fcrepo-jms should send post-translation identifiers, not the raw JCR paths" https://www.pivotaltracker.com/story/show/72262790
* travis-ci joins15:36
[travis-ci] fcrepo4/fcrepo4#2098 (sparql-bad-request - e0f9b33 : Esmé Cowles): The build passed.
[travis-ci] Change view : https://github.com/fcrepo4/fcrepo4/compare/a90de16ab1f3...e0f9b3311355
[travis-ci] Build details : http://travis-ci.org/fcrepo4/fcrepo4/builds/26412327
* travis-ci leaves
<cbeer>escowles: ping?15:45
<escowles>cbeer: yep?15:46
<cbeer>escowles: how much do you know about the way jax-rs resolves accept headers to a specific media type handler?
<escowles>cbeer: pretty much nothing15:47
<cbeer>darn. i'm trying to add framing to the JSON-LD output, but it seems like jersey strips mediatype parameters before sending them to the messagebodywriter for some reason
<escowles>cbeer: probably because it's supposed to handle that, right?15:48
<cbeer>unclear. i found some RESTEasy tickets complaining about the behavior there too
<escowles>cbeer: is there some kind of context you can stuff them in?15:49
<cbeer>escowles: if i know how jax-rs actually resolved a set of Accept headers to a single type, maybe,15:50
but it seems like you have to know what providers are available to make that determination
* dwilcox leaves15:54
<bljenkins>Yippee, build fixed!15:55
Project fcrepo4 build #1930: FIXED in 35 min: http://ci.fcrepo.org/jenkins/job/fcrepo4/1930/
* dwilcox joins15:58
<bljenkins>Yippee, build fixed!16:04
Project fcrepo-jms-indexer-pluggable build #547: FIXED in 8 min 11 sec: http://ci.fcrepo.org/jenkins/job/fcrepo-jms-indexer-pluggable/547/
* github-ff joins16:05
[fcrepo4] escowles pushed 1 new commit to jms-msg-format: http://git.io/J8dSTQ
fcrepo4/jms-msg-format b26aa74 Esmé Cowles: FedoraEvent now always returns the node path for getPath(), not sometimes a property's path
* github-ff leaves
<pivotal-bot>Esme Cowles added comment: "I've updated the PR with a small change: FedoraEvent.getPath() now always returns the node path (not sometim..." https://www.pivotaltracker.com/story/show/7226279016:06
Esme Cowles finished "fcrepo-jms should send post-translation identifiers, not the raw JCR paths" https://www.pivotaltracker.com/story/show/72262790
<escowles>cbeer: made that chagne to FedoraEvent.getPath() so it's always the node path now: https://github.com/fcrepo4/fcrepo4/pull/400/files#diff-8abb885b0fd9a06f9993c08d095af4e5R10416:07
<cbeer>escowles: thanks. that should unblock my indexer and maybe put us in business
<escowles>cbeer: it's almost like consistent behavior is easier to work with...16:08
* github-ff joins16:10
[fcrepo4] escowles opened pull request #401: Fixing a couple of Sonar warnings, adding ITs (master...sonar-coverage) http://git.io/EYu-Bw
* github-ff leaves
<pivotal-bot>Esme Cowles added comment: "This doesn't get us to 80%, but I did fix a couple of Sonar warnings and add some ITs: ""16:11
https://github.com/f..." https://www.pivotaltracker.com/story/show/70678842
<cbeer>huh. go figure.
* dwilcox leaves
<pivotal-bot>Esme Cowles finished "Unit and Integration tests to 80%" https://www.pivotaltracker.com/story/show/70678842
* travis-ci joins16:19
[travis-ci] fcrepo4/fcrepo4#2099 (jms-msg-format - b26aa74 : Esmé Cowles): The build passed.
[travis-ci] Change view : https://github.com/fcrepo4/fcrepo4/compare/5a4248c7b61f...b26aa7415022
[travis-ci] Build details : http://travis-ci.org/fcrepo4/fcrepo4/builds/26415637
* travis-ci leaves
<bljenkins>Project fcrepo-jms-indexer-pluggable build #548: UNSTABLE in 7 min 4 sec: http://ci.fcrepo.org/jenkins/job/fcrepo-jms-indexer-pluggable/548/16:42
* dwilcox joins16:52
* dwilcox leaves
* ksclarke leaves18:02
* ksclarke joins18:17
<pivotal-bot>Longshou Situ finished "Review/Update Configuration Options" https://www.pivotaltracker.com/story/show/7212282618:19
Longshou Situ added comment: "The Configuration Options Inventory is up-to-date with my best understanding now." https://www.pivotaltracker.com/story/show/7212282618:22
* ksclarke leaves18:24
<pivotal-bot>Longshou Situ added comment: "I think I've added more details to the https://wiki.duraspace.org/display/FF/Feature+Tour page and the rel..." https://www.pivotaltracker.com/story/show/7212267818:35
Longshou Situ finished "Review/Update Feature Tour" https://www.pivotaltracker.com/story/show/72122678
* edInCo leaves19:36
* scossu leaves19:46
* longshou leaves20:43
* ksclarke joins20:50
* meDavid leaves23:46
* ksclarke leaves00:37

Generated by Sualtam