Log of the #fcrepo channel on chat.freenode.net

Using timezone: Eastern Standard Time
* github-ff joins04:21
[fcrepo4-swordserver] claussni created upgrade-to-fcrepo-4.7.1 (+1 new commit): https://git.io/vMhDs
fcrepo4-swordserver/upgrade-to-fcrepo-4.7.1 578e25a Ralf Claussnitzer: ...[wip] Upgrade from Fcrepo 4.6.0 to 4.7.1...
* github-ff leaves
* travis-ci joins04:25
fcrepo4-labs/fcrepo4-swordserver#64 (upgrade-to-fcrepo-4.7.1 - 578e25a : Ralf Claussnitzer): The build has errored.
Change view : https://github.com/fcrepo4-labs/fcrepo4-swordserver/commit/578e25a38346
Build details : https://travis-ci.org/fcrepo4-labs/fcrepo4-swordserver/builds/195468761
* travis-ci leaves
* manez joins06:30
* manez_ leaves06:32
* mohamedar joins07:27
* coblej joins08:15
* dwilcox joins08:23
* dhlamb joins08:42
* whikloj joins08:54
* ajs6f joins09:08
* kefo joins09:09
* peichman joins09:30
* yamil joins09:34
* peichman1 joins09:38
<whikloj>ajs6f: API-Spec section 5.2, 3rd sentence "The effect of the request, it has one, and if if..."
Same issue in the following sentence too09:39
<ajs6f>whikloj: PR?
<whikloj>Can I issue PRs for these fixes?
<ajs6f>whikloj++
Send it, I will merge it
<whikloj>ajs6f: where is the repo? not fcrepo4, or fcrepo4-exts09:40
<ajs6f>https://github.com/fcrepo/fcrepo-specification
<whikloj>ajs6f++
* peichman leaves09:42
<whikloj>ajs6f: To confirm I just edit the HTML file directly?09:51
<ajs6f>whikloj: You should be able to edit the HTML right there in Github's web ui and shoot off a PR with a single button.09:52
<whikloj>ajs6f: ok just wanted to make sure I was doing this correctly
<ajs6f>Go for it!
* kestlund joins09:53
* bseeger joins09:54
* kestlund leaves09:55
<whikloj>ajs6f: https://github.com/fcrepo/fcrepo-specification/pull/1809:56
<ajs6f>hikloj++
whikloj++
hikloj is also awesome.09:57
* apb18 joins
<whikloj>I love that guy
* coblej leaves09:59
* kestlund joins10:00
* coblej joins
* peichman2 joins10:10
* peichman1 leaves10:11
* peichman joins10:13
<ajs6f>\who10:14
* peichman2 leaves
<barmintor>awoods: yes, I think so10:22
awoods but it may also just be incumbent on the client ajs6f: IDK if you saw my comments on FCREPO-2391
<kefo>Would anyone know what the error "java.io.IOException: No such file or directory" might mean when trying to fcr:restore a repository?10:25
FWIW, I am installing to a fedora instance that I have had to bootstrap on a cloned machine and I've had to change a few paths in the process, so I might have something misconfigured.
I'd note, however, that fedora starts up and I can PUT and GET individual resources, so it can't be too misconfigured if it is.10:26
About the error: the rfcr:restore process fails after a minute or two and outputs that particular message roughly 2300 times in the fcrepo.log10:27
<awoods>barmintor: if it can not be resolved at the Jena level, we can certainly inform clients of sparql-update recommendations, and/or we could do some checking at the Fedora-level to stop bad sparql-updates from getting to Jena.
kefo: not sure. Is it possible that your reconfiguration has changed to expected location of objects or binaries?10:28
<ajs6f>barmintor: I'm not really sure I understand the problem. It doesn't seem to violate the contract of Listener to me, but maybe I missing the poin.
<barmintor>ajs6f: that's not unfair, but I think the message set size is going to build an error into client apps, right?10:30
<ajs6f>barmintor: "message set size"?
<barmintor>I mean, it accelerates really quickly.
ajs6f: the set of statement removal messages sent to the listener10:31
<ajs6f>barmintor: I guess I don't see that as a bug, just a limitation in the implementation.
barmintor: we could probably shiim in a Set to accoutn for that.
To absorb triples that are equal to each other.
barmintor: Have you tried switching to us a GraphListener?10:32
<barmintor>right, I'm just saying the exponential growth is probably not intended, yeah, I logged the .hashcode in the trace and it's apparently the same statement 100s of times
ajs6f: instead of a propertylistener?
<ajs6f>barmintor: Yeah, or StatementListener, or whatever it now is.10:33
ModelChangedListener?
Whatever it is.
<barmintor>ajs6f: give me a few to try that, would be an interesting comparison
<ajs6f>You could put a listener on the underlying graph and you might avoid this stuff with the engine.
Although you will need a Model to actually run the update against.10:34
<barmintor>ajs6f: we already run against a model
<ajs6f>I still wouldn't mind doing RDF Patch instead.
barmintor I KNow. I'm saying that Model has an underlying Graph, and you ould listen to events on that.
barmintor: And that may avoid your problem.10:35
<kefo>awoods: Well, it certainly has something to do with the binaries, because I can't PUT one into the repository. I get the same error, but more context, so I can now see it is a modeshape config issue, somewhere.
<ajs6f>barmintor: I'm not against the behavior you want to see at the Model layer. I just don't consider the current behavior wrong per se.
<awoods>kefo: any chance it is a permissions issue?10:36
<barmintor>ajs6f: yeah, I'm reluctant to say it's a bug, but I think it is worth observing that the practical effect is bug-like.
<ajs6f>barmintor: PRs welcome.
<barmintor>ajs6f: like I was saying, it's a predictably sized set of messages, but maybe not an operable one.
ajs6f: :D
ajs6f: I tried getting the project set up, eclipse is fighting me about the shaded guava classes10:37
<ajs6f>barmintor: That's not the guarantee, as far as I know. If you want to change the guarantee, I would be cool with that and I expect the other committers would be too.
barmintor: Do a maven build first, then open all of the modules _except_ the shaded Guave in Eclipse.
barmintor: It is a known problem-- the only reason we shade in Guave is because Hadoop has failed to update its Guava.10:38
IT IS REALLY ANNOYING
It would also be fixed by OSGi, but Andy is not hearing that.
https://issues.apache.org/jira/browse/HADOOP-1131910:39
Quite the saga.
<barmintor>I imagine. I remember how happy you were to purge guava from fcrepo
<ajs6f>barmintor: I actually like Guava a lot, but find it much less needful after Java 8.
brian goetz++
<barmintor>hmm10:42
* kestlund leaves
<barmintor>I think I see what you're saying about the shim ajs6f
<ajs6f>barmintor: Really? What did I mean by that. When I saw that on IRC, I thought "He's just throwing words around, hoping they will confuse barmintor enough to let him jet out of theere and avoid work."10:44
<barmintor>if we're receiving calls to removedStatement via the default impl of one of the aggregate change methods, we could build a set internally10:45
in my tests the number of calls to removedStatement is far, far above the actual number of changed statements in the delta10:46
<ajs6f>barmintor: Egg salad! I mean, exactly!
barmintor: That probably means that there was more than one route by which that triple matched for delteion.
<barmintor>ajs6f: I mean, it might be defeated by how Jena calls us, but worth a shot10:47
<ajs6f>Route through the match (which is bascially a query).
<barmintor>ajs6f: yes, that is what happens.
<ajs6f>barmintor: SO what I would do here (and if you wait long enough, I will do it, but you will get it done a _lot_ faster) is write an astract class that impls Listener and the state of which is some Sets and another Listener.10:48
<apb18>awoods: I threw together some thoughts on "planning for an API delta document", just to start thinking about what we'd hope to achieve with such an effort: https://docs.google.com/document/d/1mwkuIlMxvQaIRDrECJz6slJ_Fw7Isw8fBQa7OEIH5Ok/edit?usp=sharing
<ajs6f>And call it "UniqueStatementListener" or something .
<barmintor>ajs6f: the product size = 2 * (num matching statements for a predicate) ^ (number of times the predicate pattern is in the update)
<ajs6f>barmintor: SPARQL will mess you up, man.10:49
<apb18>awoods: It should probably be a wiki page, but we can talk about that on the tech call.
* kestlund joins
<barmintor>and if there's additional predicate patterns, they get multipled out by that set
<ajs6f>barmintor: Keep in mind that the chief use case for Listeners is logging and figuring out how queries work.10:50
<barmintor>ajs6f: so you can see where that lazily constituted DELETE/WHERE would end up trying to remove many thousands of properties
even if they are not unique
<ajs6f>barmintor: and you can see why that's not a bug. Listeners tell you about events, not deltas.
If you want to roll up events into deltas, that's cool. But that additional work.10:51
WHich you are welcome to contribute.
:)
<barmintor>yes, agreed. like I say, not a bug, just an extremely pointy part of the API :)
<awoods>thanks: apb1810:52
<ajs6f>barmintor: I will do something about the Javadocs to make this all much clearer.10:53
I admit that it isn't at all clear now.
<barmintor>ajs6f: a tip of the hat to you
<ajs6f>That's especially nice because I know from experience that barmintor wears very stylish hats.
* coblej leaves10:56
<barmintor>ok, let's learn about the callstack
* acoburn joins10:58
* dbernstein joins
<kefo>awoods: Not a permission issue, but I had missed changing tomcat's temp setting to the new path, so I'm guessing uploads could not be written to whatever temp location they are written to before being added to fedora.10:59
* coblej joins
<ajs6f>barmintor: Can you do me abig favor a file me a Jena Jira ticket to fix those docs?11:00
<barmintor>ajs6f: I will probably remember to do that
<ajs6f>:011:01
<awoods>https://wiki.duraspace.org/display/FF/2017-01-26+-+Fedora+Tech+Meeting
* ajs6f is here
* escowles joins
* apb18 is here
* escowles is here
<acoburn>*is here*
* barmintor is here
* yinlin joins
* coblej is here11:02
<awoods>https://wiki.duraspace.org/display/FF/2017-01-26+-+Fedora+Tech+Meeting11:03
<ajs6f>bseeger++++11:04
<whikloj>lurk on! that should be a t-shirt
<barmintor>bseeger++
<whikloj>bseeger++
<acoburn>bseeger++
<dhlamb>omw
<coblej>bseeger++
* jonathangee just joined11:05
<apb18>yes, bseeger++!
* dhlamb just hopped on late, too
* ruebot in an all staff meeting11:06
* ruebot cries
<ajs6f>ruebot: all staff meeting sounds like fun https://www.etsy.com/market/wizard_staff11:07
<whikloj>ajs6f++11:08
* ruebot looks for gandalf11:10
<yinlin>4.7.x during the year and 5.x end of year. ++
<whikloj>Go 5.011:14
<barmintor>awoods: if it's what the partners want, but I imagine a lot of people running snapshot builds :_
<acoburn>so master would now target 5.x?11:15
<whikloj>acoburn: that is my understanding
* Informatician joins
<acoburn>I would prefer more releases to fewer11:16
<ajs6f>What acoburn says
smaller, more frequent changes is more conducive to stability than large, infrequent changes
<escowles>we could backport those to 4.7.2 if there's interest
<ajs6f>There is the speed of change and there is the predicatbility of change, and those are two diff things11:17
I suspect that some people are wanting more predictability but are asking for less speed.
<barmintor>4.7.x-stable ahoy
<kestlund>++
<ajs6f>Jena is moving from every six months to every three months.11:19
* th5 joins
* bseeger leaves11:20
<whikloj>5.0-alpha
fair enough11:21
<ajs6f>That would be lovely.11:23
I thikn you pretty much need OSGi for that, tho'.
That management is where OSGi comes in.11:25
Or doesn't.
<dhlamb>we have that same problem in islandora
it requires automation
<awoods>dhlamb: can you comment when there is space?11:27
<ajs6f>The Java ecosystem is different because there are good systems for exactly this problem already in wide use for fifteen years.
<acoburn>right now there are very few "clear boundaries" between the fcrepo modules (kernel-modeshape and http-commons is a good example)11:29
I've been working on this recently, and it's all about "clear boundaries": https://github.com/acoburn/trellis11:30
<ajs6f>Half of the utility of OSGi or Jigsaw or these sorts of things is precisely that they enforce discipline abot modularity and boundaries.
<acoburn>ajs6f++
<ajs6f>I'm not confident that fcrepo4 as a software development effort ha the resourcing to get there.
But that's awoods' problem.11:31
<dhlamb>the other danny's concerns are well founded. we certainly suffer from it in 7.x-1.x islandora
<acoburn>ajs6f: it's a herculean task to take the current codebase there
<dhlamb>as well
<ajs6f>acoburn: Exactly. Specifically: http://www.perseus.tufts.edu/Herakles/stables.html
<apb18>Delta doc planning: https://docs.google.com/document/d/1mwkuIlMxvQaIRDrECJz6slJ_Fw7Isw8fBQa7OEIH5Ok/edit11:32
<ajs6f>I have to run. apb18++ for ths work
* ajs6f leaves
<kestlund>Penn State will help with API11:41
<whikloj>awoods: I can dedicate some time
* dhlamb I can help. It certainly will affect some of my future design decisions
<whikloj>awoods: +1 on sending it out and the proposed deadline11:44
<kestlund>Agreed +1 to send out
<escowles>+1
<barmintor>+1
<coblej>+1
<yinlin>+2
+1
<apb18>+1
<barmintor>STROOOOOOOOOOP11:45
kestlund: we were trying to avoid April 1 :/11:46
<dhlamb>april 2nd then :D
<barmintor>kestlund: just because of the Fools
<whikloj>kestlund++
barmintor++
<escowles>monday, april 3rd?11:47
<coblej>Should we remove "It's as drafty as an abandoned old clapboard farmhouse." before sending it out?
<barmintor>probably
<kestlund>+1 to April 3
<whikloj>coblej: PR?
<barmintor>acoburn: no, please11:49
<kestlund>it would be helpful to have multiple deadlines, then, I think
<barmintor>kestlund++
I think that's a good idea, too
<kestlund>I do really like the W3C process of 2 working implementations
<escowles>yes, multiple deadlines and multiple implementations11:50
<dhlamb>'when do we say its done?' that's always the question
<kestlund>we can grab the language and staging from W3C
<barmintor>I fully intend to implement on Cavendish
<escowles>we should talk to the iiif editors about this — that's the best managed spec i know the maintainers of...
* peichman leaves
<kestlund>IIIF follows W3C process to a large extent, too11:51
<escowles>i think that's right
<barmintor>escowles: that's why we're trying to get Stroop and azaroth42 on the horn, but maybe we should try the board as a group?
<kestlund>I'm on the coordinating committee and can push to that group, which also includes all the IIIF editors
<barmintor>kestlund++ // I'm running out of pluses kestlund11:52
<kestlund>hah!
<barmintor>awoods: that captures my concerns, yes
* peichman joins
<acoburn>FWIW, in my impl, there is no concept of ref integrity11:58
<whikloj>preach dhlamb
<escowles>+1
* ad96 joins
<escowles>we could (optionally) enforce referential integrity on updates instead...
gotta run to another call12:00
<kestlund>Thank you, all! Nice to visit!
<barmintor>bye escowles
* acoburn leaves
* kestlund leaves
<dhlamb>bye everybody
<escowles>ciao, barmintor
<barmintor>awoods: if I don't grab a sandwich I won't get lunch today, so brb
* Informatician leaves
<barmintor>awoods: should be < 5 minutes
<awoods>kefo: did you have a parting comment?12:01
barmintor: ok
* yinlin leaves
<awoods>dbernstein ^^12:03
<dbernstein>barmintor and awoods: I’m looking at the meeting calendar invite. Did I not specify a place to meet?
<kefo>awoods: Nothing much other than we should return to that conversation. I've gots nothing special to say other than 1) as someone who has liked and benefited from the notion of referential integrity in the past, I am starting to think the minuses are outweihghing the pluses and 2) to point out, assuming it matters, that removing the ability to Prefer:InboundReferences would mark a change with the proposed API spec, yes?
<dbernstein>where are you guys? On the fedora line?
<awoods>dbernstein: we can use the same line as the tech call... in < 5 minutes... waiting on barmintor12:04
<barmintor>omw12:06
<coblej>whikloj: PR submitted to remove drafty farmhouse section from API spec
<dbernstein>awoods ^^12:07
<whikloj>coblej++ # I don't have permissions to that repo, but I'm sure someone (awoods/acoburn/barmintor) will review it
<apb18>kefo: I believe Prefer:InboundReferences is currently a MAY in the spec doc, so I don' think removing support for it in the current impl would change the spec doc per se.
i.e. it'd still be usable for implementations that can support it (e.g. those based on a triple store)12:08
<whikloj>kefo/apb18: It is currently MAY - http://fcrepo.github.io/fcrepo-specification/#additionalPreferValues
<apb18>kefo, whikloj ... it could possibly affect the *delta* doc, though!12:10
<barmintor>awoods: buffalo chicken wrap12:11
<whikloj>apb18: only if that change is made in the current impl, correct?
which is still in discussion
<apb18>whikloj, right, or proposed to change
<whikloj>apb18: agreed12:12
<kefo>I was just raising it as a thing.12:18
Or possible thing.
<whikloj>kefo: no worries, it is still a thing for the current impl12:28
<barmintor>awoods: https://github.com/fcrepo4/fcrepo4/tree/rwp-mode-queries12:35
* peichman leaves12:38
* peichman joins12:40
* kestlund joins12:41
* coblej leaves
<kestlund>Documentation for IIIF API review process: http://iiif.io/api/annex/notes/editors/#evaluation-and-testing
<awoods>thanks, kestlund
<kestlund>@awoods This may not be as thorough as you want, but I can forward other questions and clarifications if you'd like
* github-ff joins13:03
[fcrepo4] escowles created mode5.3 (+1 new commit): https://git.io/vMjNT
fcrepo4/mode5.3 549e185 Esmé Cowles: Updating to Modeshape 5.3.0.Final
* github-ff leaves
* kestlund leaves13:04
* peichman leaves
* peichman joins
* github-ff joins
[fcrepo4] escowles opened pull request #1167: Updating to Modeshape 5.3.0.Final (master...mode5.3) https://git.io/vMjN3
* github-ff leaves
* coblej joins13:05
* bseeger joins13:07
* coblej leaves13:10
* coblej joins13:12
* coblej leaves13:14
* coblej joins13:15
* travis-ci joins13:17
fcrepo4/fcrepo4#4925 (mode5.3 - 549e185 : Esmé Cowles): The build passed.
Change view : https://github.com/fcrepo4/fcrepo4/commit/549e185553de
Build details : https://travis-ci.org/fcrepo4/fcrepo4/builds/195617617
* travis-ci leaves
* github-ff joins13:27
[fcrepo4] awoods pushed 1 new commit to master: https://git.io/vMjpS
fcrepo4/master 2df32de Esmé Cowles: Updating to Modeshape 5.3.0.Final (#1167)
* github-ff leaves
* peichman leaves13:30
* peichman joins13:45
* bseeger leaves13:51
* coblej leaves13:56
* coblej joins14:05
* bseeger joins14:11
* bseeger leaves14:42
* coblej leaves15:16
* bseeger joins15:21
* coblej joins15:33
* peichman leaves16:24
* peichman joins16:26
* escowles leaves16:31
* apb18 leaves16:55
* coblej leaves16:58
* th5 leaves17:04
* bseeger leaves17:05
* coblej joins
* coblej leaves17:20
* yamil leaves17:41
* peichman leaves
* whikloj leaves18:00
* kefo leaves18:06
* travis-ci joins18:20
ualbertalib/fcrepo4-oaiprovider#55 (master-hydranorth-1340-doi_metadata - f0610f4 : Jeffery Antoniuk): The build passed.
Change view : https://github.com/ualbertalib/fcrepo4-oaiprovider/commit/f0610f491ba3
Build details : https://travis-ci.org/ualbertalib/fcrepo4-oaiprovider/builds/195712483
* travis-ci leaves
* github-ff joins18:37
[fcrepo4] dbernstein opened pull request #1168: HTML UI: External Content redirects to binary description (master...fcrepo-2387) https://git.io/vDe7i
* github-ff leaves
* mohamedar leaves19:35
* dwilcox leaves21:24
* dhlamb leaves23:35

Generated by Sualtam