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

Using timezone: Eastern Standard Time
* apb18 leaves00:00
* thomz joins03:06
* dwilcox joins08:06
* dwilcox leaves08:39
* apb18 joins
* dwilcox joins08:50
* peichman joins09:03
* whikloj joins09:06
* peichman1 joins09:07
* peichman leaves09:08
* bseeger joins09:13
* peichman1 leaves09:41
* peichman joins09:42
<whikloj>awoods: ping09:44
<whikloj>awoods: If I put/post a non-rdf file to Fedora 4 with an invalid sha1 checksum, I get a 409 Conflict. If I put/post a non-rdf file to Fedora 4 with an invalid MD5 checksum, I get a 201 Created. Should I not be warned, or is the assumption that no one uses MD5 anymore?
<ajs6f>There's no way that is correct behavior, no matter who is or isn't using MD5.09:53
<awoods>whikloj: an unrecognized checksum algorithm would ideally result in a 4xx error.09:54
<whikloj>awoods/ajs6f: yeah, I would have thought an error that we don't support MD5
I'll open a ticket
<awoods>whikloj: see: https://github.com/fcrepo4/fcrepo4/blob/master/fcrepo-http-api/src/main/java/org/fcrepo/http/api/FedoraLdp.java#L79009:55
<whikloj>awoods: yeah I was looking at that. I'll see if I can cleanly throw an error if there is not a sha1 checksum09:56
<whikloj>awoods/ajs6f: Already was a ticket - https://jira.duraspace.org/browse/FCREPO-184210:11
<awoods>whikloj: are you on it?10:12
<whikloj>awoods: Well, I'll definitely work the Exception side...We might like the MD5 and alternate from a migration perspective, but I'd rather use the MD5 for validation on resource creation, but still store a SHA-1 checksum10:13
<ajs6f>There's transmission checksum and there's persistence chcksum.10:14
<whikloj>ajs6f: are they handled separately?10:15
<awoods>whikloj: if you can work the exception side, please create a separate ticket and link it to FCREPO-1842, since, as you noted, FCREPO-1842 really is coupling two issues.
<ajs6f>whikloj: I have no idea. I'm just saying that they are two different things, whether or not we conflate them.
<whikloj>awoods: ok10:16
ajs6f: gotcha
<ajs6f>barmintor: Do you remember how the namespace alias stuff works in Trippi? is there some way that AliasManagers get populated with that default set of prefixes? I'm trying to help Dan Davis get his gear all working, and he's run into the problem that Islandora code uses invalid SPARQL that relies on the "magic aliases" in F3. You are about the only person left I can think of who would remember this.10:18
<barmintor>ajs6f: it's configured in the spring/fcfg10:32
ajs6f: it's just a dumb map
ajs6f: https://github.com/fcrepo3/fcrepo/blob/master/fcrepo-server/src/main/resources/fcfg/server/fedora-base.fcfg#L427-L43410:33
* acoburn joins
<ajs6f>barmintor: My question is really how does it get into the Trippi stuff. E.g. is there code in o.f.server.resourceIndex somewhere that hands the values in that map to Trippi code? Thanks for any dim memories!10:37
<barmintor>ajs6f: oh, yes: the map is injected
ajs6f: the interface https://github.com/fcrepo3/trippi/blob/master/trippi-core/src/main/java/org/trippi/AliasManager.java10:38
<ajs6f>barmintor: Ah, cool. So stuff in o.f.s.resourceIndex, should receive that map via injection, and push it into Trippi somehow or another? Okay, I'll go sniff around for that..
barmintor: Yeah, and DefaultAliasManager.
barmintor: Because when you look at trippi-mulgara or trippi-mpt, they don't know anything about those aliases. They know about AliasManagers. So something is pushing that info in to them.10:39
<barmintor>ajs6f: making that stuff configurable was one the last areas of active dev I had in the fcrepo3 codebase before it was "fix performance and shut it down"
<ajs6f>barmintor: That is good luck for me. Like I said, if you don't remember this stuff, I don't know who would.10:40
<rarian>ajs6f: I fixed my islandora SPARQL prefixes with this hack: https://gist.github.com/Rarian/e809c39968bd6b243aaf1a030636d43b10:43
<ajs6f>rarian: so you are find-and-replacing the aliases at the Islandora level, per query?10:44
<ajs6f>rairan: Might darn well be the simplest thing. I'll forward that to ddavis— thanks!10:45
<rarian>Tangentially related to this ticket I created: https://jira.duraspace.org/projects/ISLANDORA/issues/ISLANDORA-172610:46
* dchandekstark joins
<ajs6f>rarian: Yeah, fundamentally, the problem here is that Islandora isn't issuing valid SPARQL. But as far as getting 1.7 stuff fixed, I'm not holding my breath. CLAW 4EVA!10:47
<rarian>ajs6f: Which is why I patch Islandora during my deploy process.
<ajs6f>Or 7.x, or however the versioing works for Islandora.
rarian: Where are you?
<ajwagner>University of Toronto
<ajs6f>rarian: Cool, thanks.10:48
* thomz leaves11:00
* ajs6f is here.
<barmintor>if you're nasty.11:03
<ajs6f>Oh, that takes me back. Just wait 'til _my_ "wardrobe malfunction".
<bseeger>*is here *
<awoods>ajs6f: will you please take notes?11:06
<ajs6f>awoods: I am typing some things. Whther or not you find them intelligible we will see.11:07
<ajs6f>awoods: It is not my forte.
<ajs6f>I like the sound of the word "BOM".11:09
<barmintor>awoods: I know that was dumb, but I wanted you to know I was still on the line :P11:10
<ajs6f>Is anything interested involunteering to play with our BOMs.?11:11
* mikeAtUVa joins
<ajs6f>BOM BOM BOM.11:14
acoburn: I am not getting all this in the notes.11:15
<acoburn>ajs6f: I can add to the notes afterwards11:16
* ajwagner is calling in late11:21
<barmintor>acoburn++ // I am pro- this approach, and would advocate as soon as Jena bridge is done11:26
<ajs6f>There is a future in which Fedora itself starts to makes sense.11:27
<whikloj>makes sense
<barmintor>awoods: yes, this is what I am sayin.11:33
<acoburn>+1 // and it should be compatible w/ API-X11:34
<mikeAtUVa>Are there ways to configure the connection pooling for MySQL in ISPN? Do we really only get the options listed here: http://docs.jboss.org/infinispan/7.0/configdocs/infinispan-cachestore-jdbc-config-7.0.html11:35
<whikloj>+1 to having an alternative11:38
<barmintor>awoods: I'm still trying to look at that11:39
ajs6f: my office is very talkative right now
<ajs6f>barmintor: Want me to yell "SHUT UP!" really loud?
<barmintor>ajs6f: please don't yell this is a library11:40
<ajs6f>barmintor: Put your shawl on and do some knitting.
<barmintor>Lo! I am become the bottleneck!
these Duke versioning bugs and the logging change I would really like to get out11:42
awoods: does this mean that we are releasing 4.5.2, and MODE 5 is still 4.6.011:43
<ajs6f>Release early, release often.
<bseeger>should it be 4.5.3 then? Or still large enough to be 4.6?
<ajs6f>If it's too much of a burden, fix th releae process.
<awoods>barmintor: no, it would be 4.6.0
* dwilcox_ joins
<bseeger>(whoops, meant 4.5.2)
* mohamedar joins11:44
<ajs6f>The principle of most dangerous surprise.
<whikloj>so if people can stick with leveldb and migrate later, why could we not move to Modeshape 5?11:45
<ajs6f>whikloj: You could. It's jut more work.11:46
* dwilcox leaves
<whikloj>ajs6f: so is the concern that its not backwards compatible? Sorry I'm missing something11:47
* yinlin joins
<whikloj>quite a few things actually
<ajs6f>whikloj: The concern is that we have no migration tools to offer.
whikloj: That's not good community management.
<yinlin>So 2.b is not included in 4.6.0 release?
Agenda 2.b11:48
* dchandekstark leaves11:50
<ajs6f>I'm gong to have to leave at 12 or so.11:55
awoods: Is there a ticket?
Oh, that sucks.11:56
That's postmature optimization needed.
awoods: Did you lose the call, or did I?
<whikloj>its very quite
<ajs6f>Now I can.
<whikloj>its very quiet
<barmintor>awoods: you disappeared!
<whikloj>^^ that
<ajs6f>awoods is fading in and out of existence again. I hate when he does tht.11:57
<yinlin>on and off
<bseeger>yes, on and off. Silence…
<ajs6f>Does anyone know what that ticket its?
<whikloj>I got dumped from the call
<barmintor>so did I11:58
<bseeger>I keep hearing sonar pings…
<ajs6f>I'm still on, but it's just making weird pings.
<whikloj>freeconferencecallhd is under load
I got robot lady welcoming me
<ajs6f>Now I have to go, so I'll put the notes I have in the meeting page and someone else can take up from here.
<awoods>it looks like the party is over
<ajs6f>If there is any more meeting to be had.
That was _some_ party.11:59
<awoods>I will pose the 4.6.0 release planning to the committer list.
<ajs6f>Bye-bye everyone!
<awoods>Thoughts on Agenda items #6 or #7?12:00
<awoods>any reason not to release fcrepo-build-tools immediately?
<acoburn>awoods: +1 on releasing now
<barmintor>awoods: ship it
<awoods>I will release it.12:01
* mohamedar1 joins
<acoburn>awoods: re event ontology — are you asking for a PR against fcrepo4/ontology?
* yinlin leaves
<awoods>acoburn: yes... if that makes sense to you all.
does it make sense to you all to move fcrepo-event-ontology into fcrepo4/ontology?12:02
<ajs6f>Yes, it's part of the spec suit.
<acoburn>awoods: I think it make sense to put the ontology in the fcrepo4 github org
moving it into fcrepo4/ontology seems like a logical place for it
* mohamedar leaves
* ajs6f leaves
<acoburn>awoods: I would note that the webac ontology is separate from fcrepo4/ontology
awoods: by the logic above, shouldn't that also go into fcrepo4/ontology?12:04
<awoods>acoburn: it is a matter of committers' preference for organization of core ontologies...
acoburn: I would be happy to have all of the core ontologies in fcrepo4/ontology.12:05
acoburn: including webac
<acoburn>awoods: I really don't have an opinion one way or the other
<awoods>acoburn: but as you noted, consistency would be good12:06
<acoburn>awoods: yes, I care more about consistency than about whether the ontologies are together or separate
awoods: say we put these in fcrepo4/ontologies — should they go into separate subdirectories? I bet they use slightly different XSLT documents12:07
<awoods>acoburn: for simplicity and consistency, let's transfer the ownership of fcrepo-event-ontology to the fcrepo4 organization... then consolidate upon agreement.12:08
<acoburn>awoods: I'm mostly concerned that you'll get oddities like this: http://fedora.info/definitions/1/0/access/2016/06/02/ObjState
see the "prefixes" in the HTML
it says "audit:#" — but it's the ObjState ontology
that's what I want to avoid12:09
<awoods>acoburn: sure. We will likely want to standardize our ontology layout and transformations... but it is not necessary at the moment.
acoburn: would you be willing to simply transfer ownership to the fcrepo4 GH org for now?12:10
<acoburn>awoods: just did
* manez joins
* dwilcox_ leaves12:44
* dwilcox joins
* dchandekstark joins12:49
* diegopino joins12:52
* ddavis joins13:00
* whikloj is late, but here for API-X13:04
<diegopino>acoburn? API-X call?13:06
<acoburn>diegopino: yes, joining now
<diegopino>acoburn cool
<bseeger>*is here *13:10
* mikeAtUVa leaves13:16
<whikloj>totally agree with elliot13:21
* ajs6f joins13:25
* martinjd joins13:27
<diegopino>awoods: exactly.13:41
* github-ff joins13:49
[fcrepo4] whikloj opened pull request #1063: Throw an exception if a non-SHA1 digest is passed (master...FCREPO-2075) https://git.io/vKmA4
* github-ff leaves
<diegopino>apb18: right. agree with that14:00
* diegopino leaves
<whikloj>ajs6f: the anyMatch() wants a predicate, is there a shortcut or is .anyMatch(s -> s.equals("sha1")) the best option?14:04
<ajs6f>whikloj: "sha1"::equals
<whikloj>ok...I'm seeing a pattern14:05
<ajs6f>whikloj: What do you mean?14:06
<whikloj>ajs6f: based on your previous review comment around String::toLowerCase, I'm starting to see the pattern for these...functional interfaces I think14:07
<ajs6f>whikloj: Method references?
<whikloj>ajs6f++ # thanks14:08
<ajs6f>whikloj: Ain't nothing but aJ thing.
* ajs6f leaves14:09
* ajs6f joins
* barmintor leaves14:12
* manez leaves
* apb18 leaves14:52
* github-ff joins15:05
[fcrepo4] awoods opened pull request #1064: Allow resources that are referenced by other versioned resources to b… (master...fcrepo-2074) https://git.io/vKYtG
* github-ff leaves
* github-ff joins15:08
[fcrepo4] ajs6f pushed 1 new commit to master: https://git.io/vKYqs
fcrepo4/master c3eeee4 Jared Whiklo: Throw an exception if a non-SHA1 digest is passed (#1063)...
* github-ff leaves
* dchandekstark leaves15:09
<awoods>acoburn: in reference to discussion during today's tech meeting, the "ldp:contains" children are automatically limited in the HTML UI and optionally limited with non-HTML REST requests: https://github.com/fcrepo4/fcrepo4/blob/master/fcrepo-http-api/src/main/java/org/fcrepo/http/api/FedoraLdp.java#L22715:17
<acoburn>awoods: yes, but this was what I was talking about: https://github.com/fcrepo4/fcrepo4/blob/master/fcrepo-kernel-modeshape/src/main/java/org/fcrepo/kernel/modeshape/rdf/impl/ChildrenRdfContext.java#L60-L6215:19
there are two calls to FedoraResource::getChildren15:20
* github-ff joins15:22
[fcrepo4] whikloj opened pull request #1065: Add a logger warning when using fcrepo-connector-file (master...FCREPO-2028_2) https://git.io/vKYYo
* github-ff leaves
<acoburn>awoods: using an AtomicInteger, we should be able to make only a single traversal of child resources15:35
* travis-ci joins15:36
fcrepo4/fcrepo4#4552 (master - c3eeee4 : Jared Whiklo): The build passed.
Change view : https://github.com/fcrepo4/fcrepo4/compare/ddee309f31c6...c3eeee4675ef
Build details : https://travis-ci.org/fcrepo4/fcrepo4/builds/143139397
* travis-ci leaves
<ajs6f>acoburn: Does it have to be on the fly? Why not maintain a count?15:37
<acoburn>ajs6f: +1 on maintaining a count
<ajs6f>Amortize that cheese.
* ajs6f leaves15:38
<ajwagner>I thought we talked about that back in February...15:42
* peichman leaves15:45
<awoods>ajs6f/acoburn: maintaining the count will almost certainly be a headache of the scale seen when trying to manage "last-modified-date".15:52
<acoburn>awoods: yes, I'm sure it will be
<awoods>acoburn: all things considered, capping the count at X (say 1000) seems functional and reasonable.15:53
acoburn: the full count can always be found in an external index.
* github-ff joins15:54
[fcrepo4] escowles closed pull request #1064: Allow resources that are referenced by other versioned resources to b… (master...fcrepo-2074) https://git.io/vKYtG
* github-ff leaves
<acoburn>you mean the triple would say `<> fedora:hasChildren 1000` even if the actual representation has > 1000 ldp:contains values?
<whikloj>if were aren't providing an accurate count, then I wouldn't provide any.
<awoods>I was thinking `<> ldp:contains 1`
I was thinking `<> ldp:contains 10`
I was thinking `<> ldp:contains 100`
I was thinking `<> ldp:contains 1000`
I was thinking `<> ldp:contains 1000+`
for more than 1000
<whikloj>thats kind of a non-standard way of counting...not sure how I feel about that15:56
<acoburn>"1000+" isn't an xsd:nonNegativeInteger
<awoods>acoburn: that is a valid point15:57
<acoburn>why are we providing a count in the first place?
<awoods>acoburn/whikloj: I think having a count in the common case is easy, useful, and reasonable.
acoburn/whikloj: If the count is over X, we can leave out the triple.15:58
acoburn/whikloj: Thoughts?
<whikloj>awoods: again, that seems incorrect. Do we provide `<> ldp:contains 0` ever?
Just that otherwise we remove a count that would normally appear...15:59
<acoburn>whikloj: we _do_ provide fedora:numberOfChildren 0
(if there aren't any children)
<awoods>acoburn: right, my example was misleading
<whikloj>acoburn/awoods: ok, then I can assume that if `<> fedora:numberOfChildren X` doesn't exist then the count is 1000+16:00
<awoods>whikloj: that would be true, in the impl I was suggesting.
<acoburn>whikloj: with RDF the absence of a triple implies nothing
* dchandekstark joins16:01
<whikloj>darn... acoburn is correct.
acoburn/awoods: would changing the definition of fedora:numberOfChildren to allow a negative integer in the case of N+1 children be workable?16:02
for N = 1000 or whatever we decide16:03
<awoods>whikloj: what use case are trying to address?
<acoburn>whikloj: a negative integer???16:04
<awoods>whikloj: what use case are <you> trying to address?
<whikloj>sorry, I just think that we can't have a triple that is sometimes correct. So we need a way to say `<> fedora:numberOfChildren 1`16:05
`<> fedora:numberOfChildren 10`
`<> fedora:numberOfChildren 1000`
`<> fedora:numberOfChildren 0`16:06
but if larger than 1000, `<> fedora:numberOfChildren -1`
<awoods>whikloj: I think we are suggesting the triple always be correct.
whikloj: ...but the triple may not always exist.
<whikloj>awoods: ok, but if I can't rely on the triple being there then I would likely plan for some other way of getting the count. So why maintain the triple?16:07
<awoods>whikloj: it is informative for the common case.16:08
<whikloj>awoods: ok
* martinjd leaves16:09
<awoods>whikloj: Is there a value of N below which represents the common case (90%) that you believe provides benefit when including the additional triple?16:10
* peichman joins16:11
<whikloj>awoods: no, I agree with what you are saying about common case. Just trying to avoid people asking "how come I don't get X triple on Y resource".16:12
<awoods>whikloj: That is a valid concern.
<whikloj>awoods: Assuming people properly distribute their resources, this should not be an issue. But my mother used to say something about assuming anything16:13
<awoods>whikloj: since we are talking about ldp:contains relationships, even proper distribution may not help.16:14
<awoods>whikloj: PAIRTREEs are skipped in determining children.
whikloj: We could provide a default, and allow requests to "limit" the number of children counted and returned.16:15
whikloj: Similar to: https://github.com/fcrepo4/fcrepo4/blob/master/fcrepo-http-api/src/main/java/org/fcrepo/http/api/FedoraLdp.java#L227
<whikloj>awoods/acoburn: to clarify this counting does complete right, its just slow?16:17
<acoburn>whikloj: your characterization is correct, as I understand things
<awoods>whikloj: when I exceed 1M children, I have waited an entire weekend with out the count completing...
whikloj: ..before stopping the request.16:18
<ajwagner>So on the implementation side, we'd try to get N children, if we get less than N children we return the numberOfChildren triple, and if we get N children we wouldn't return the triple?
<whikloj>acoburn/awoods: But it would probably finish....eventually. In which case I like the default or request parameter
ajwagner: that is one option in play16:19
<awoods>whikloj: looking at it more closely, using the existing 'limit' Accept parameter may make the most sense: https://wiki.duraspace.org/display/FEDORA4x/RESTful+HTTP+API+-+Containers#RESTfulHTTPAPI-Containers-GETRetrievethecontentoftheresource16:21
whikloj: currently the default is effectively -1, but we could change that to 1000... or something.
<whikloj>awoods: so limit would also affect the maximum value of the fedora:numberOfChildren triple?16:22
<awoods>whikloj: yes
<whikloj>awoods: I'm good with that16:23
<awoods>whikloj: is that confusing... if you ask for a container limiting to 75 children, that fedora:numberOfChildren also be 75?
<whikloj>awoods: it is not intuitive... but I don't have a better solution. anyone? acoburn? ajwagner?16:24
<ajwagner>awoods whikloj: So I set my limit to 20, and a container has 20 or more children I would expect to get a hasChild triple, but not a numberOfChildren triple?16:25
<acoburn>limiting the number of ldp:contains triples should *not* change the value of fedora:numberOfChildren16:26
<whikloj>ajwagner: no, in this case you would get a <> numberOfChildren 20
Then I guess removing the fedora:numberOfChildren triple is the best option16:27
<acoburn>I would strongly advocate either removing it or storing it as a static (internal) property
<awoods>acoburn: do you agree with removing the triple altogether?
<acoburn>awoods: I am not against it
awoods: personally, I have no use for that triple
<awoods>acoburn/ajwagner/whikloj: it sounds like removal of that triple is the consensus.16:29
<awoods>acoburn/ajwagner/whikloj: and it is already affected by the Accept: limit=xx header.
acoburn/ajwagner/whikloj: sorry, "it" being the actual children that are returned as "ldp:contains"16:30
<whikloj>awoods: ok, so this is probably improving the accuracy of the response16:31
* dwilcox leaves
<awoods>whikloj: I think it was accurate before this update. The fedora:numberOfChildren was always accurate (when it was small enough to return), and the "limit" header just truncated the number of children returned as ldp:contains.16:32
<whikloj>awoods: right, but now you can limit the children returned and not get an incorrect triple for ldp:contains16:33
<awoods>whikloj: each child resource gets its own "ldp:contains" triple.16:35
<whikloj>awoods: oops sorry, so did Limit affect the fedora:numberOfChildren triple?16:36
<awoods>whikloj: No, the fedora:numberOfChildren always returned a full count.
whikloj: But when the count was high, it took a very long time to return.16:37
<whikloj>awoods: right, ok then it was correct. Just painfully slow
<awoods>whikloj: we are trying to address the issue of the response time being unacceptable for large counts.
<awoods>whikloj: exactly
* whikloj leaves17:02
* dwilcox joins17:04
* peichman leaves17:05
* bseeger leaves17:08
* acoburn leaves17:11
* dwilcox leaves17:54
* mohamedar joins18:01
* mohamedar1 leaves18:04
* mohamedar leaves18:06
* dchandekstark leaves
* dchandekstark joins18:15
* dchandekstark leaves
* dchandekstark joins18:39
* dchandekstark leaves18:44
* github-ff joins19:07
[fcrepo4] awoods opened pull request #1066: Remove fedora:numberOfChildren predicate (master...fcrepo-1880) https://git.io/vKYHg
* github-ff leaves
* github-ff joins19:35
[fcrepo-build-tools] awoods tagged fcrepo-build-tools-4.4.2 at c2d4782: https://git.io/vKY79
fcrepo-build-tools/fcrepo-build-tools-4.4.2 e6e77a8 Andrew Woods: [maven-release-plugin] prepare release fcrepo-build-tools-4.4.2
* github-ff leaves
* travis-ci joins19:37
fcrepo4/fcrepo-build-tools#36 (fcrepo-build-tools-4.4.2 - e6e77a8 : Andrew Woods): The build passed.
Change view : https://github.com/fcrepo4/fcrepo-build-tools/commit/e6e77a86793e
Build details : https://travis-ci.org/fcrepo4/fcrepo-build-tools/builds/143199249
* travis-ci leaves
* github-ff joins19:43
[fcrepo-build-tools] awoods pushed 2 new commits to master: https://git.io/vKY54
fcrepo-build-tools/master e6e77a8 Andrew Woods: [maven-release-plugin] prepare release fcrepo-build-tools-4.4.2
fcrepo-build-tools/master 52c4c8f Andrew Woods: [maven-release-plugin] prepare for next development iteration
* github-ff leaves
* travis-ci joins19:45
fcrepo4/fcrepo-build-tools#37 (master - 52c4c8f : Andrew Woods): The build passed.
Change view : https://github.com/fcrepo4/fcrepo-build-tools/compare/59d88afce9e7...52c4c8f0c284
Build details : https://travis-ci.org/fcrepo4/fcrepo-build-tools/builds/143201032
* travis-ci leaves
* mohamedar joins20:23
* mohamedar leaves20:25
* mohamedar joins21:05
* mohamedar leaves21:13
* mohamedar joins22:07
* mohamedar leaves22:08

Generated by Sualtam