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

Using timezone: Eastern Standard Time
* manez joins04:17
* manez leaves04:21
* manez joins05:17
* manez leaves05:22
* manez joins06:18
* manez leaves06:23
* manez joins07:19
* manez leaves07:23
* manez joins08:00
* dwilcox joins08:19
* coblej joins08:30
* github-ff joins09:05
[fcrepo-import-export] escowles deleted container-three-step at 5622e84: https://git.io/vipGS
* github-ff leaves
* github-ff joins
[fcrepo-import-export] escowles deleted sort-files-first at 28ba016: https://git.io/vipG9
* github-ff leaves
* acoburn joins09:08
* dwilcox leaves09:15
* ajs6f joins09:34
* dwilcox joins09:53
<ajs6f>acoburn: Have you tried "RDF/XML" (RDFXML_PLAIN) with RDFDataMgr?09:56
* coblej leaves
<acoburn>ajs6f: yes, but there, you pass in a Model
ajs6f: and so the content of the Stream has already been consumed by that model09:57
ajs6f: actually, that's how it works right now in my branch
* peichman joins09:59
* coblej_ joins10:00
<ajs6f>acoburn: What about RDFXMLPlainWriter?10:01
Oh, that only writes graphs.10:02
* awoods joins
<acoburn>ajs6f: I was just looking at that; right, you can't stream to it
<ajs6f>acoburn: No, you can, but you have to impl Graph, which you won't want to do and shouldn't.
<acoburn>ajs6f: I was trying to avoid implementing any jena interfaces10:03
<ajs6f>acoburn: Yeah, like I say, you shouldn't.
<awoods>ruebot: Where did the import/export work land last week?10:04
<ruebot>awoods: dan just sent a note out to the lists10:05
<awoods>ruebot: I saw that...10:06
ruebot: Are we in a position to send out a message to the list seeking testing/feedback?10:07
<ruebot>awoods: the only big outstanding thing is a bug awead found on thursday. esme is working on it, but has other priorities this week.
awoods: yes. my plan is to have something drafted for you to review later on today.
<awoods>ruebot: perfect, thanks again.
<ruebot>awoods: np!10:08
awoods: https://wiki.duraspace.org/display/FF/2016-09-26+Performance+-+Scale+Meeting
* bseeger joins10:10
* mjgiarlo joins10:12
<ajs6f>acoburn: What do you get when you try to use StreamRDF.getWriterStream?10:13
<acoburn>ajs6f: it's some sort of exception
<ajs6f>sorry StreamRDFWriter.10:14
<acoburn>ajs6f: right, that's what I assume you meant
<ajs6f>"Failed to find a writer factory for ***"?
<acoburn>ajs6f: something like that — I can check10:15
ajs6f: org.apache.jena.riot.RiotException: Failed to find a writer factory for RDF/XML/plain10:16
<ajs6f>acoburn: Yeah, that's what I was afriad of.
<acoburn>ajs6f: that's with this code: final StreamRDF stream = getWriterStream(output, RDFXML_PLAIN);10:17
ajs6f: another reason not to use RDF/XML
<ajs6f>acoburn: I've thikn you've spent about as much time on this as it will ever deserve.10:23
* peichman leaves
<acoburn>ajs6f: I think so too :-)
* peichman joins10:25
* whikloj joins10:36
<ruebot>https://wiki.duraspace.org/display/FF/2016-09-26+Performance+-+Scale+Meeting10:59
* thomz leaves11:00
* ylchen joins11:01
* dhlamb is here11:02
* coblej_ leaves11:03
<awoods>https://wiki.duraspace.org/display/FF/2016-09-26+Performance+-+Scale+meeting11:04
* grosscol joins11:05
* coblej joins
* coblej leaves11:06
* coblej joins
* coblej_ joins11:08
* coblej leaves
<ruebot>I solemnly swear that I will run a performance test, the whole performance test, and nothing but the performance test, so help me under pains and penalties of perjury.11:10
<ylchen>https://wiki.duraspace.org/display/FF/Virginia+Tech+Results+-+Test+1+-+2nd11:11
<ruebot>ylchen++
* dbernstein joins11:12
<ylchen>-Dfilesize_min=24000000011:17
-Dfilesize_max=250000000
230MB11:20
average
<ruebot>dbernstein: https://wiki.duraspace.org/display/FF/Performance+and+Scalability+Test+Plans11:22
dbernstein: Down at the bottom, "Child pages"
dbernstein: there is a summary page for each set of tests, with results pages for each institution... down at the bottom in the child pages.
* ruebot has been doing it11:30
grosscol++11:33
* coblej_ leaves11:39
* coblej joins
* coblej leaves11:41
* coblej joins11:47
<ylchen>sorry got to go. cheers!11:59
* ylchen leaves
* bseeger leaves12:01
* coblej leaves12:02
* coblej joins12:06
* github-ff joins12:16
[fcrepo4] acoburn opened pull request #1102: Remove Sesame OpenRDF libraries; rework stream-based serialization code (master...fcrepo-2242) https://git.io/vipSH
* github-ff leaves
<dbernstein>Performance and Scale meeting notes: https://wiki.duraspace.org/display/FF/2016-09-26+Performance+-+Scale+meeting12:18
* acoburn leaves12:30
* coblej leaves12:46
* coblej joins12:54
* bseeger joins12:55
* ajs6f leaves12:56
* coblej leaves12:58
* coblej joins13:01
* amccarty joins13:03
* coblej leaves13:05
* coblej joins13:07
* coblej leaves13:11
* coblej joins
<ruebot>awoods: drafting instructions for stakeholders now. i'm partially through, and questioning my approach...13:15
<awoods>ruebot: what is your approach?13:16
<ruebot>awoods: ...something that is quickly turning into the longest email ever :-(13:17
awoods: https://docs.google.com/document/d/165lW20AMk6EFnhpozPOBIDKJ9P1FenIpsvDb2h0Jby8/edit?usp=sharing
<awoods>ruebot: It looks like your email is more focused on the "how" of testing and less on the "why". Maybe it would make sense to capture testing steps on the wiki and use the community email to highlight the work that has been completed... with a pointer to the wiki for those who have time to test.13:23
* dwilcox leaves
<ruebot>awoods++
awoods: in the stakeholder testing page, should we have them use fcrepo-vagrant, and if so, what branch?13:25
<awoods>ruebot: I think vagrant may be too much overhead for simple testing13:30
ruebot: the one-click may be easiest13:31
ruebot: 4.6.0
<ruebot>awoods: ok, so stick with my current path on the "How"13:33
<awoods>ruebot: I would be inclined to have folks test their own data... instead of the canned datasets.13:34
* dwilcox joins
<awoods>ruebot: the meat of the instructions would be around the import/export options and how to use the tool.
<ruebot>awoods: ok. well, we aleady have that.13:35
* jjtuttle leaves13:37
<awoods>ruebot: which makes the task even easier
* ajs6f joins13:42
<ruebot>awoods: ok. check it out now. let me know if that works.13:47
<awoods>ruebot: I will make comments when my next meeting ends, at 3pm ET. Thanks13:49
<ruebot>awoods++
* acoburn joins14:06
* ajs6f leaves14:09
* ajs6f joins
* coblej leaves14:19
* coblej joins14:26
* coblej leaves14:30
* peichman leaves14:32
* coblej joins14:33
* peichman joins14:37
* coblej leaves14:38
* peichman leaves14:39
* coblej joins14:40
* peichman joins14:44
* coblej leaves
* coblej joins14:46
* coblej leaves14:47
* coblej joins
* osmandin joins14:49
* peichman leaves14:50
* osmandin leaves14:51
* peichman joins14:57
* osmandin joins14:59
<acoburn>awoods: ping15:05
* bseeger leaves15:06
* osmandin leaves15:09
<awoods>acoburn
<acoburn>awoods: do you know where the content-length header is set for containers?
awoods: I was looking at fcrepo-188215:10
awoods: in particular the content-length of 0 for HEAD requests
awoods: I'm not sure it's possible to know the content-length w/o reading the entire stream15:11
<ajs6f>Isn't content-length invariantly 0 for HEAD responses? I would think Jersey would do that for us.
Or is that the content you would have gotten if you sent GET?
content-length
<acoburn>ajs6f: I think the headers are supposed to be the same as w/ a GET request
<ajs6f>That would make sense.15:12
<awoods>acoburn: Doesn't the HTTP spec have accommodation for unknown content-length?
<acoburn>awoods: good question
awoods: we do the right thing for binaries, fwiw
awoods: "in the case of the HEAD method, the size of the entity-body that would have been sent had the request been a GET"15:13
awoods: ^^^ from RFC 2616
<awoods>acoburn: that is what I would expect15:14
acoburn: as ajs6f suggests, we are likely getting content-length from Jersey for containers.
<acoburn>awoods: that's what I thought
awoods: so for fcrepo-1882, should we just ignore the part about the Content-Length header on HEAD requests15:15
awoods: for LDP-Cs
<ajs6f>We're getting content-length from Jersey, but other headers are from local markets.
<acoburn>awoods: ajs6f: how about this: I'll issue a PR addressing fcrepo-1882, but only the parts about Vary and Accept-Post15:17
<awoods>acoburn: sounds good... then we can create a new ticket for just the Content-Length/HEAD part
<acoburn>awoods: ok15:18
<ajs6f>If we factor our tickets thoroughly enough, maybe there won't be any work left.
<acoburn>ajs6f: btw, my French is _really_ rusty — is it "n'est un titre…" or "c'est un titre" — or I can just revert it to what it was15:19
* mohamedar joins15:20
<ajs6f>acoburn: https://en.wikipedia.org/wiki/The_Treachery_of_Images
This is not a French title.15:21
acoburn: You can thank me later.15:22
<acoburn>ajs6f: I'll keep that in mind
ajs6f: I'll just change it to German. At least that's a language that I can actually speak
<ajs6f>acoburn: Klaatu barada nikto.15:24
<mohamedar>acoburn: Got a question on the fcrepo-camel FcrepoProducer. Shouldn't the getMetadataUri (https://github.com/fcrepo4-exts/fcrepo-camel/blob/master/src/main/java/org/fcrepo/camel/FcrepoProducer.java#L158) method return a URI with /fcr:metadata suffix for binary (non-rdf) resource?15:26
<acoburn>mohamedar: yes, it does15:27
mohamedar: it follows the Link header, which happens to have a /fcr:metadata suffix
* dwilcox leaves15:28
<mohamedar>acoburn: I see. Thanks!
* coblej leaves15:30
* dwilcox joins
* coblej joins15:46
* bseeger joins
* github-ff joins15:53
[fcrepo4] acoburn opened pull request #1103: Update HTTP Headers in response (master...fcrepo-1882) https://git.io/vihCt
* github-ff leaves
* peichman leaves15:55
* mohamedar1 joins15:57
* mohamedar2 joins15:58
* mohamedar1 leaves
<awoods>ruebot: I just sent you a request for "comment" access on your email doc.16:00
* peichman joins
* mohamedar leaves16:01
<ruebot>awoods: done
<awoods>ruebot: thanks
* github-ff joins16:09
[fcrepo4] acoburn opened pull request #1104: Remove DELETE/MOVE/COPY methods from Allow header on RepositoryRoot resources (master...fcrepo-2158) https://git.io/vih8L
* github-ff leaves
* amccarty leaves16:14
<acoburn>ajs6f: do you think we can mark this as resolved: https://jira.duraspace.org/projects/FCREPO/issues/FCREPO-199216:17
<ajs6f>acoburn: I theeeeeenk so. Trying to think of anything else we could do...16:18
<awoods>acoburn: I am not sure there is room for debate, given: https://github.com/fcrepo4-exts/fcrepo-connector-file
<acoburn>awoods: meaning?16:19
<awoods>acoburn: meaning, it is done
* manez leaves
<acoburn>awoods: ok, that's my opinion, too
<ajs6f>The arguable remaining things to do would be to get a messages to the community explaining what has happened and asking for maintainers.16:27
* dwilcox leaves
<acoburn>and whikloj was planning to do that, right?
<whikloj>acoburn: I certainly can, sorry I was waiting for awoods to get back. I couldn't remember the group that wanted file-connector to remain.16:29
<awoods>acoburn: whikloj asked me to do that... but I am waiting on the 4.7.0-RC message to go out first.
acoburn/whikloj: did I miss that message?
<whikloj>awoods: yes
<ajs6f>That RC had the heck messaged out of it.
<whikloj>awoods: https://groups.google.com/forum/#!topic/fedora-tech/9Eb92E6Clto16:30
ajs6f: I did fail to jibber-jabber it, but I was reaaaaaaally close to starting the new trend of release names
<ajs6f>whikloj: I noticed that, and I was disappointed, but you are the release manager.16:31
<whikloj>ajs6f: Maybe next time, assuming I don't leave this release in a flaming heap
<awoods>whikloj: great. I will send out the community request for fcrepo-connector-file maintainers.
<whikloj>awoods++16:32
<ajs6f>whikloj: You are worried about leaving a steaming fiasco in a flaming heap?
That's arguably an improvement.
<acoburn>ajs6f: awoods: so I tried a COPY operation on the repository root. It's quite singular as to what happens; I would encourage you to try it16:33
<ajs6f>acoburn: Is this the kind of thing I should have a couple of beers before for best effect?16:34
<acoburn>ajs6f: probably
<ruebot>awoods: https://github.com/fcrepo4-labs/fcrepo-sample-dataset/pull/17
<ajs6f>acoburn: because that's not a burden or problem.
<acoburn>ajs6f: I'd recommend a heady topper16:35
* acoburn leaves16:37
<ajs6f>acoburn: Tried it— that looks almost correct to me.16:40
curl -X COPY -H "Destination: http://localhost:8080/rest/copy" http://localhost:8080/rest/
It didn't create the "copy" resource, but other than that, looks okay.
Did you see something else?
Maybe I didn't drink enough first.
Oh, but a different attempt gives:16:42
javax.jcr.nodetype.ConstraintViolationException: Unable to add child 'copy' with primary type 'mode:root' to parent at /62/3b/68/ea/623b68ea-543d-42c2-a319-47658ea5d2a5 with primary type 'nt:folder' and mixins '{fedora:Container,fedora:Resource}' in workspace 'default' of repository 'repo' because:
- child's primary type 'mode:root' does not satisfy parent's child definition: nt:folder/* (required primary types = [nt:hierarchyNode])
Yeah, we should fix that to somehow strip the 'mode:root' type so that people could copy their root to wherever.
* bseeger leaves16:44
<ruebot>awoods: caught i stupid typo by me right after you merged https://github.com/fcrepo4-labs/fcrepo-sample-dataset/pull/18
caught a*
* ruebot sighes
* ajs6f leaves16:55
* grosscol leaves16:56
* peichman leaves17:08
* mohamedar joins17:11
* peichman joins17:12
* mohamedar2 leaves17:13
* coblej leaves17:20
* manez joins
* manez leaves17:25
* whikloj leaves18:00
* peichman leaves18:02
* mjgiarlo leaves18:04
* mjgiarlo joins18:18
* manez joins18:21
* manez leaves18:25
* mohamedar leaves18:40
* manez joins19:22
* manez leaves19:27
* awoods leaves19:46
* manez joins20:23
* manez leaves20:27
* dwilcox joins20:44
* manez joins21:23
* manez leaves21:28
* manez joins22:24
* dbernstein leaves22:27
* dbernstein joins22:28
* dbernstein leaves
* dbernstein joins22:29
* manez leaves
* dwilcox leaves23:14
* manez joins23:25
* manez leaves23:30
* dbernstein leaves23:34
* manez joins00:26
* manez leaves00:30
* manez joins01:26
* manez leaves01:31
* manez joins02:27
* manez leaves02:31
* manez joins03:28
* manez leaves03:32