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

Using timezone: Eastern Standard Time
* dwilcox joins07:48
* dwilcox leaves08:23
* dwilcox joins08:25
* dhlamb joins08:38
* bseeger joins09:05
* peichman joins09:08
* ajs6f joins09:13
awoods: "We installed Virtuoso on an AWS large instance to manipulate the 99B triples down to the more manageable dataset of around 6B triples (chemical synonyms and descriptors), that we needed."09:15
awoods: They aren't actually _serving_ 99Gt at all.
* dwilcox leaves09:26
* dwilcox joins09:31
* bseeger leaves09:43
* youn joins09:44
* whikloj joins09:52
* grosscol joins
<whikloj>ajs6f++ # Did some testing of two Fedora 3s running and sharing a Blazegraph triplestore. Read-only on trippi-sparql seemed to work great.09:53
* th5 joins
<ajs6f>whikloj: Thanks for… BLAZING THAT TRAIL.
ruebot_away: ^^^09:54
<whikloj>ajs6f: https://media.giphy.com/media/KUrKDE59ZaiS4/giphy.gif
* bseeger joins09:55
* awoods_ joins10:00
* awoods leaves
<ajs6f>AAAARRGGG10:05
We lost all the logging for yesterday: http://irclogs.fcrepo.org/2016-11-02.html
which had the conversation about header vs URIs for atomic ops. Damn.
<whikloj>doh10:13
* acoburn joins10:16
<ajs6f>whikloj: Quick, write all that back down from memory.10:17
<whikloj>ajs6f: sorry I wasn't listening the first time....10:18
<ajs6f>whikloj: That's okay, I'm sure you got as much out of it as we did.
<whikloj>ajs6f++
* kefo joins10:22
* peichman leaves10:36
* peichman joins
<ajs6f>dhlamb:whikloj: have you been following the discussions about spec issues, particularly create-on-PUT and headers vs. URIs for transactions10:37
?
<whikloj>ajs6f: I listened to some of your and barmintor's discussion, have been reading Tom's comments in the atomic op spec10:38
<ajs6f>whikloj++
I would like to hear the CLAW voice in these conversations.10:39
<whikloj>ajs6f: I am less clear on the create-on-PUT issue, as for headers vs URIs for transactions... I kinda like the Header idea. But there aren't many people doing batches/atomic ops as separate requests10:40
ajs6f: So we would not have much in the way of community to latch on to10:41
<ajs6f>whikloj: Not sure what you mean by "separate requests"?10:42
<whikloj>ajs6f: All the transaction over HTTP stuff I could find use multi-part messages/requests to handle a "batch". We do it as multiple separate requests.10:43
<ajs6f>whikloj: the create-on-PUT thing is this: should we require Fedora impls to support creating new resources via PUT? If we do, it means those new resources may not be contained by anything. It means you won't be able to walk your way up to a repository "root". There will be various "regions" with a repository (or as I increasingly think of it, various repositories within a server).
whikloj: Oh, right. we turned away from that early on because a) it's not RESTful (addresses multiple resources with one request) and b) it leads to _massive_ requests. But there are arguments for it, I'm sure.10:44
<whikloj>ajs6f: So in the current impl we have create-on-PUT, right?10:45
ajs6f: I guess I would ask why would we not allow that?
<ajs6f>whikloj: We do, but we auto-create all the "intermediate nodes" and invent containment for them. We wouldn't require that in the spec.10:47
* barmintor joins10:48
hey, does the fcrepo-vagrant run against mysql or postgres
<whikloj>ajs6f: So if I said `curl -XPUT http://localhost:8080/fcrepo/new1/new2/actualThing`, we wouldn't require a new impl to support creating new1 and new2 if they don't exist. So this request could fail
barmintor: Not out of the box, I guess we could add some config to support it.10:49
<barmintor>whikloj what does it run against?
<whikloj>barmintor: file-simple
<barmintor>hmm
<ajs6f>whikloj: No, it would succeed, but a subsequent immediate GET to http://localhost:8080/fcrepo/new1/new2 or http://localhost:8080/fcrepo/new1/ would 404.
whikloj: They would fail until/unless you go ahead and actually _create_ those guys.10:50
<whikloj>ajs6f: hmm ok
<ajs6f>whikloj and it would _not_ be the case that http://localhost:8080/fcrepo/new1/new2 or http://localhost:8080/fcrepo/new1 ldp:contains http://localhost:8080/fcrepo/new1/actualThing10:51
http://localhost:8080/fcrepo/new1/actualThing would not be ldp:contain -ed by anything.
It would be a new "repository root", independent of http://localhost:8080/fcrepo/
* dbernstein joins10:52
<ajs6f>(BTW, here's your multitenancy)/
<whikloj>ajs6f: But could we add a ldp:contains triple if you wanted too?
<ajs6f>whikloj: If you created those intermediate guys at LDPCs, then yes, you could later add containment.
<barmintor>but then you are also making a statement about modifiability of ldp:contains via PATCH10:53
<ajs6f>barmintor: No, couldn't you use PUT against http://localhost:8080/fcrepo/new1/actualThing? Although I have no problem with PATCH modifying containment on the face of it.10:54
Why are all these URIs getting underined?
<whikloj>So you can click on them :P
<barmintor>or you are opening a subsequent question about how POST /new1, Slug: new2
<ajs6f>barmintor: What is that questions?10:55
<barmintor>what happens
<ajs6f>new2 gets built, same as it would if actualThing never existed. new2 does not ldp:contain actualThing. What is the problem?
<barmintor>ajs6f: you can't use PUT to change the containment of the resource10:56
* MarcusBarnes joins
<ajs6f>barmintor: Why not?
(given non-basic containers.
<whikloj>ajs6f: So if I PUT http://localhost:8080/fcrepo/new1 it would not be a LDPC, and if I wanted it to contain something I then need to change it to an LDPC?10:57
<ajs6f>whikloj: You could PUT it as an LDPC.10:58
<whikloj>ajs6f: right sorry, but by default if I just did `curl -XPUT http://localhost:8080/fcrepo/new1` it won't create an LDPC
<barmintor>ajs6f: 5.2.4.1, but also it's the wrong container
<ajs6f>or not. Your choice. And barmintor has argued elsewhere (IIU him correctly) that the function of changing nonC to C should be impl decided.
barmintor: What do you mean the wrong container?10:59
* coblej joins
<whikloj>https://wiki.duraspace.org/display/FF/2016-11-03+-+Fedora+Tech+Meeting
<barmintor>ajs6f: if /new1/new2/aThing is sparse
* emanuilCL joins
<barmintor>ajs6f: then I create a container /new1/new2
PUT /new1/new2/aThing cannot modify /new1/new211:00
's containment
(and also, PUT isn't supposed to modify containment)
<ajs6f>I see that by 5.2.4.1, but I still don't see what you mean by "the wrong container".
<barmintor>ajs6f: the containment triple is on /new1/new2
or it would be
<bseeger>* is here *11:01
<barmintor>if you are replacing /new1/new2/aThing, you are not modifying /new1/new2
* coblej is here
<ajs6f>barmintor: Except for 5.2.4.1, it could be wehever you want it. Indreict conteainer.
* ajwagner is on the call
<ajs6f>On my way.
<acoburn>*is here*
* dhlamb is here11:02
* ylchen joins
* escowles joins11:03
<whikloj>Double Dannys!!!
<awoods>https://wiki.duraspace.org/display/FF/2016-11-03+-+Fedora+Tech+Meeting11:05
<ajs6f>barmintor: Basically, I hear you making a really good argument against the idea that you can introduce containment after the fact, based on 5.2.4.1 (althought 5.2.4.1 seems dumb to me). But that doesn't argue against create-on-PUT. It's just part of how create-on-PUT would work.
* ajs6f is here
<barmintor>ajs6f: it's the weird subsequent implications/questions that make me think silence is golden11:06
<ajs6f>barmintor: If you can't introduce containment afterwards ("once a root, always a root") then there are no subsequent complications, that I can see.
<whikloj>ajs6f: So you can only PUT new roots?11:07
<barmintor>ajs6f: I just foresee frustration and lots of cross-frustration
<ajs6f>whikloj: no, but if you do PUT a new root, it can never move inside some other containment
barmintor: There's a topological way to think about this. It seems pretty intuitive to me.
<barmintor>ajs6f: I wanted that URI, but I made it a root, so I deleted it, but I can't reuse URIs11:08
<ajs6f>barmintor: I like the terminology of calling each region a repository.
barmintor: You can reuse URIs. I fixed that in the spec
<barmintor>ajs6f: you *might* be able to reuse URIs
<ajs6f>barmintor: We can't prevent impls from intentionally doing stupid things.11:09
barmintor: That's not the job of the spec, for my money.
<barmintor>ajs6f: but if we think that is liegitimately optional, it's mean to MUST things that will require it
* barmintor shrugs
I think it's a mistake to allow URI reuse
<ajs6f>barmintor: ask cbeer why he wants to MUST it. I don't. I want to MAY it, and describe how it works if you do11:10
barmintor: You specifically commented to say that you don't object to not strengthening the SHOULD NOT to MUST NOT on URI reuse!
<barmintor>ajs6f: I have no problem with a non-normative section explaining scenarios
<ajs6f>barmintor: I think (and Tom JOhnson thinks, as far as I can tell) that we need to say something normative about creat-on-PUT, if it is allowed.11:11
<barmintor>ajs6f: that is my feeling about the spec, but that is not my feeling about an impl
<ajs6f>barmintor: we are working on the spec together. We keep our impl feels in a different box.
<barmintor>I know. That's why I didn't object to leaving it "should not" :)11:12
* mikeAtUVa had that error in the past, but couldn't rule out that his repo wasn't already corrupted (ISPN issue) at the time the backup was made.11:13
<barmintor>ajs6f: IIRC, there is also a weird think where the w3 suite tries a PUT with a Slug if you allow PUT
<ajs6f>barmintor: Can you give a precise understanding ( I mean a list of scenarios/problems) with create-on-PUT? I want to bring this conv to a conclusion so I can get to work writing.
barmintor: The suite is buggy.
<barmintor>ajs6f: I won't argue with that.11:14
ajs6f: but it was a headache w/ Cavendish
<ajs6f>barmintor: I am less concerned with the suite than I am with your prognostications.
<barmintor>ajs6f: I'll try to write sometinhg up this afternoon, but it will be ca 4:30
* mikeAtUVa uses tomcat, but not postgres.11:15
<acoburn>we've done this w/ pgsql/tomcat w/ no errors, but it was a small repo
<ajs6f>barmintor++++
barmintor: I want to POP THIS ZIT.11:16
<barmintor>ajs6f: I don't like this metaphor.
<ajs6f>barmintor: "Sploot!"
<barmintor>gross
<ajs6f>Fedora 4: Icky!11:17
escowles++11:19
* ayd joins
<whikloj>escowles++ kefo++
<ajs6f>Ghosts and phantoms of repositories past.11:20
whikloj: How's that release gong?
<whikloj>ajs6f: great11:21
<ajs6f>:thumbs-up:
<whikloj>you might say "releas-tastic"
<ajs6f>_You_ might say that. _I_ would make some disgusting reference to facial blemishes.
<whikloj>Sploot!
* apb18 joins11:22
<ajs6f>The Fedora-bone is connected to the— MODESHAPE bone,
etc.
* apb18 joins late11:23
<ajs6f>Word.11:26
<barmintor>awoods: backports++
<whikloj>mikeAtUVa++11:27
<barmintor>afk11:28
<acoburn>whikloj: unless you're starting fresh…11:29
<ajs6f>Go ahead and migrate your non-existent repo.11:30
DONE!
<whikloj>dd if=/dev/null of=/dev/null11:32
<ajs6f>muted?11:34
<acoburn>mike's not working
mic
awoods: you described it pretty well
awoods: I'm back11:36
<bseeger>awoods: I may be around as well, if people wanted help with some workshop.
<ajs6f>PCDM flavored?11:37
Asymptotically impossible.11:40
It's asymptotically sensible.11:42
barmintor: Why didn't we reuse the info:fedora opaque internal URI thing? Didn't we have some reason?11:43
barmintor: Don't you have a PR out that does just exactly that: id <-> id?
<barmintor>I don't know. We need design docs.11:44
ajs6f: I also had to take my headphones off to talk to people in my cube, I'm not on cal
<ajs6f>We should have written those docs a long time ago. I think it's a bit too late for that.
barmintor: Do you not have a PR out that make the identifier conversion stuff work purely on ids, instead of retireveing resources?
<barmintor>I did, I do, but it's out of date11:45
<ajs6f>oh, ok.
Say that again, acoburn.11:46
+1 to what escowles.
i saying
<whikloj>yep11:57
<apb18>Sounds reasonable to me!
<escowles>+1
<ajs6f>+"!"
<whikloj>ajs6f++11:58
<ajs6f>https://wiki.duraspace.org/display/FEDORAAPI/Fedora+Specification11:59
https://github.com/fcrepo4-labs/derby/issues/11
<whikloj>and barmintor12:00
<ajs6f>bye bye12:01
<whikloj>Cheers!
<escowles>tech meeting minutes are in the agenda: https://wiki.duraspace.org/display/FF/2016-11-03+-+Fedora+Tech+Meeting
<ajs6f>how do you make an action item?12:02
<escowles>i'm not sure — maybe it's a macro, or maybe you can just type in "[] foo" to create one?12:03
* MarcusBarnes leaves
<ajs6f>ah, you can do Insert -> Task List
* ajs6f leaves12:15
* ylchen leaves12:17
* thomz leaves
* bseeger leaves
* ylchen joins12:18
* ylchen leaves12:22
* coblej leaves
* th5 leaves12:25
* escowles leaves12:27
* ylchen joins12:28
* ylchen leaves12:33
* ylchen joins12:39
* bseeger joins12:42
* ylchen leaves12:44
* coblej joins12:59
* ylchen joins13:00
* ylchen leaves13:01
* acoburn leaves13:03
* coblej leaves13:11
* coblej joins13:14
* bseeger leaves13:23
* emanuilCL leaves13:33
* acoburn joins13:40
<peichman>acoburn: trying to upgrade to fcrepo-camel-toolbox 4.6.0 as an interim before moving to 4.6.1, and we are running into SSL re-negotiation errors between Karaf and the Apache server that is reverse proxying our Solr; were there any changes from 4.5.2 to 4.6.0 that you can think of that might be triggering stricter or different SSL handling?13:44
<acoburn>peichman: I'll check...13:45
<peichman>acoburn: thanks13:46
acobrun: on the Apache side we are running 2.2, with TLSv1 enabled and SSLv2 and SSLv3 disabled
we don't have TLSv1.2 support on the Apache side yet13:47
<acoburn>peichman: were you previously running 4.5.2?
<peichman>yep
<acoburn>peichman: there were a number of changes b/t 4.5.2 and 4.6.0 that were _supposed_ to have addressed SSL
<peichman>and it was connecting fine over SSL; I should say we were running Mohamed's patch to 4.5.2
but that got merged into the 4.6.0, AFAICT13:48
<acoburn>peichman: the big change between 4.5.2 and 4.6.0 is that all the configurations required the https scheme in URLs
<peichman>acoburn: this is the commit I am looking at https://github.com/fcrepo4-exts/fcrepo-camel-toolbox/commit/2488daf5abd3db4ee0130e7082bf7c66916674c2
acoburn: which we have in our org.fcrepo.camel.indexing.solr.cfg13:49
<acoburn>peichman: so, if Solr is at https://solr.example.com/core, you need to have the full scheme defined in the cfg
<peichman>acoburn: yeah
<acoburn>peichman: are you all using system properties to configure the client?13:50
peichman: the _http_ client
<peichman>acoburn: yes, we are setting the truststore, keystore, and protocol version
<acoburn>peichman: what version of camel are you runnin?13:51
peichman: IIRC, the useSystemProperties param doesn't actually work until version 2.18.0 (released last month)
<peichman>acoburn: though looking at the camel docs, I'm not sure it honors the https.protocols property
ah
acobrun: do you mean the fcrepo-camel component?13:52
<acoburn>peichman: no, camel-core
<peichman>acoburn: lemme check
<acoburn>peichman: feature:list | grep camel-core
<peichman>acoburn: ah, we are only on 2.17.113:53
acoburn: let me try updating that to 2.18.0
<acoburn>peichman: I'm working toward a 4.6.2 release of the camel toolbox, but there are a number of intermediate steps that must be addressed first
<peichman>acoburn: cool; we are moving slowly towards deploying fcrepo 4.7 with toolbox 4.6.1+13:54
<acoburn>peichman: I have a bunch of things in the air at the moment, but they should settle soon-ish
<peichman>acoburn: I know that feeling :-)13:55
acoburn: I took a quick look at the custom webapp builds link you sent me, and I will probably want to pick your brain about it at a later date
<acoburn>peichman: I was just going to ask you about that13:56
peichman: it was _really_ easy to create
peichman: but it requires some knowledge of the existing spring configuration for Fedora
peichman: you're welcome to copy the code — I can push it to github it that would make it easier13:57
<peichman>acoburn: the one hurdle we might face in adopting it straight off is the gradle vs. maven thing; we are still solidly a maven shop13:58
<acoburn>peichman: it would take me five minutes to re-do it in maven
<peichman>acoburn++13:59
acoburn: so the general idea is that it is a essentially a config-only repo that you can use to build custom webapp using standard upstream artifacts?
<acoburn>peichman: exactly14:00
<peichman>acoburn: how easy is it to swap in our own custom web.xml?
<acoburn>peichman: clone the repo and replace that file
peichman: I also wanted a custom web.xml file that I could manage, hence the repo14:01
<peichman>acoburn++
acoburn: that sounds like exactly what we want14:02
<acoburn>peichman: https://github.com/acoburn/amherst-fedora-webapp14:04
* github-ff joins14:10
[fcrepo4-vagrant] awoods opened pull request #68: Update to Fedora 4.7.0 (master...fcrepo-2116) https://git.io/vXco8
* github-ff leaves
* github-ff joins
[fcrepo-camel] acoburn opened pull request #131: Update to fcrepo-java-client 0.2.x (master...fcrepo-2287) https://git.io/vXcoB
* github-ff leaves
<peichman>acoburn: okay, one last question (for now), what is the best way to upgrade the camel feature to 2.18.0? I've tried just a feature:repo-add and feature:install, but now I appear to have both versions running side-by-side, and I'm not sure if the toolbox is picking up the newer version14:15
<acoburn>peichman: for big updates like this, I typically shut down karaf, remove the entire $KARAF_HOME/data directory and then start from a clean slate14:16
peichman: before installing any fcrepo-camel-* artifacts, you'd want to install camel itself14:17
peichman: feature:repo-add camel 2.18.0
peichman: and then feature:install camel-core
<peichman>acoburn: we are using the bootFeatures config in Karaf, so I will try adding that to the beginning of the feature list
<acoburn>peichman: that's an even better way to do it14:18
* ajs6f joins
<acoburn>peichman: the way the camel toolbox was written, it installs a particular version of camel, and I think I'm going to change that for the next version — to provide a lot more flexibility (for cases like this)14:19
<peichman>acoburn++
acoburn: even with deleting the data dir and explicitly adding camel 2.18.0 to the features boot list, I am still getting both versions of camel running when I start up Karaf14:22
<acoburn>peichman: yes, I think that's fcrepo-camel-toolbox doing its thing — I'll change that for the next version14:23
peichman: if you can wait a week or two
<peichman>acoburn: we may have to, it looks like14:24
acoburn: if not, I'm assuming there'd be a way for us to go in and do a custom build (ugh!) that forced it to 2.18.0?
<acoburn>peichman: this is the line that forces it: https://github.com/fcrepo4-exts/fcrepo-camel-toolbox/blob/master/toolbox-features/src/main/resources/features.xml#L414:25
peichman: the pom.xml file defines camel.version as 2.17.3 (or some 2.17.x version)14:26
peichman: here's a branch with maven included: https://github.com/acoburn/amherst-fedora-webapp/tree/maven14:35
* escowles joins14:36
<peichman>acoburn++14:37
<ajs6f>I hate it when acoburn goes above and beyond. It raises expectations for everyone.14:43
* osmandin joins14:56
* apb18 leaves14:58
* osmandin leaves15:07
<acoburn>ajs6f: related to those identifier converters, do you have an opinion as to whether it should be a Converter<Resource, Resource> or Converter<String, String> ?15:22
ajs6f: where Resource is a Jena Resource
ajs6f: I'm starting this with Converter<String, String>15:23
<ajs6f>That's why I would do.
what
<acoburn>ok, cool15:24
there are stages of the conversion where the value isn't really a URI, and I want to avoid silly conversion errors because of the limitations of what is a valid Resource15:25
<ajs6f>I can imagine situations into which we might go where we want ids that are not URIs. UUIDs or something15:26
* dwilcox leaves15:32
* peichman leaves15:33
* peichman joins
* dwilcox joins15:34
* escowles leaves15:37
* escowles joins15:38
* github-ff joins16:09
[fcrepo4-vagrant] whikloj pushed 2 new commits to master: https://git.io/vXcAd
fcrepo4-vagrant/master bdf1ff1 Andrew Woods: Update to Fedora 4.7.0...
fcrepo4-vagrant/master 1c556bb Jared Whiklo: Merge pull request #68 from awoods/fcrepo-2116...
* github-ff leaves
* osmandin joins16:11
<peichman>acoburn: regarding your custom Fedora build config, to externalize the Spring, Modeshape, or ActiveMQ config files I would just set the approproate properties in my JAVA_OPTS?16:14
acoburn: e.g. JAVA_OPTS="$JAVA_OPTS -Dfcrpeo.spring.configuration=file:/etc/fcrepo/spring.cml"16:15
* osmandin leaves16:16
<acoburn>peichman: yes, exactly16:18
<peichman>acoburn: awesome16:19
acoburn: so as long as all the dependencies are compiled in, changing which ones were enabled and how would be as simple as editing the spring config and restarting the webapp?16:20
<acoburn>peichman: yes — if you want to add or remove external dependencies, you'd manipulate the maven dependencies and any relevant spring configuration16:23
<peichman>acoburn: very nice16:24
<acoburn>peichman: oh, and just an FYI, I didn't enable resource filtering, so the build number doesn't actually appear on the index.html page16:25
<peichman>acoburn: I feel like this definitely has legs, I will be interested to see where you take it
<acoburn>peichman: I'll keep you posted
* coblej leaves16:26
<peichman>acoburn: that is, unless SSL kills me first X-(
<acoburn>peichman: I've had days (make that weeks) like that
* dwilcox leaves16:35
* grosscol leaves
* ajs6f leaves16:41
* mikeAtUVa leaves17:11
* acoburn leaves17:12
* peichman leaves17:15
* github-ff joins17:19
[fcrepo4-vagrant] whikloj closed pull request #53: Add configuration support for AuthZ and no-AuthZ (master...fcrepo-2110-master) https://git.io/v6lV7
* github-ff leaves
* youn leaves17:30
* whikloj leaves18:00
* dwilcox joins18:06
* dwilcox leaves18:17
* kefo leaves18:18
* escowles_ joins22:09
* escowles leaves22:14

Generated by Sualtam