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

Using timezone: Eastern Standard Time
* escowles joins05:05
* escowles leaves05:09
* billmcm joins05:56
* billmcm leaves06:00
* escowles joins06:16
* billmcm joins07:10
* billmcm leaves07:31
* escowles leaves07:48
* dwilcox joins07:55
* billmcm joins
* dwilcox leaves07:56
* escowles joins07:59
* billmcm leaves08:01
* dwilcox joins08:09
* escowles leaves08:19
* escowles joins08:31
* acoburn joins08:47
* ksclarke leaves08:48
* ksclarke joins09:05
* ksclarke leaves09:09
* dhlamb joins09:22
* escowles leaves09:23
* ksclarke joins09:25
* whikloj joins
* escowles joins09:37
* peichman joins10:10
* github-ff joins10:19
[fcrepo4] acoburn opened pull request #962: DO NOT MERGE (master...fcrepo-1312) http://git.io/vR8vT
* github-ff leaves
* ajs6f joins10:39
* billmcm joins10:47
* escowles leaves11:08
* escowles joins11:10
* escowles leaves11:14
<ajs6f>acoburn: I don't like the fact that in your PR, there is a identity for RdfStreamContext that is separate from the graph. I don't understand what that identity _is_.11:18
* escowles joins11:20
<acoburn>ajs6f: that's fair
<ajs6f>acoburn: I'm just trying to ride the wave of identity politics. See how _topic_al I can be?
<acoburn>ajs6f++
ajs6f: the thing I don't understand, though, is this issue of the topic()11:21
ajs6f: in the current impl of RdfStream, topic just seems to be along for the ride11:22
<ajs6f>acoburn: topicis the point of the graph. Not in the idiomatic sense of "purpose", in the mathematical sense of "rooted graph".
<acoburn>ajs6f: there's nothing in the class the uses that (other than for setting an identity for the instance)
ajs6f: yes, I understand that11:23
<ajs6f>acoburn: It's not machinery _in_ the class that uses that, it's machinery _outside_ the class that uses that.
<acoburn>ajs6f: right, that's what I thought
<ajs6f>acoburn; E.g. to display appropriately labelled HTML views.
acoburn: It's about two inches away from a named graph.
<acoburn>ajs6f: so right now the current impl (and my impl) are combining two things11:24
1) a stream of RDF triples
2) some context bearing element (e.g. the topic())
ajs6f: what about separating those two?
<ajs6f>acoburn: No, I wouldn't put it that way. I would say that we have in hand one thing: a rooted graph (possibly infinite) and the current impl impls that, and your impl… sort of does.
acoburn: Consider an RdfStream with no set topic.11:25
* travis-ci joins
ualbertalib/fcrepo4-oaiprovider#25 (oai_etdms - 28f6499 : Piyapong Charoenwattana): The build passed.
Change view : https://github.com/ualbertalib/fcrepo4-oaiprovider/compare/3d9735ba973b...28f6499ceca2
Build details : https://travis-ci.org/ualbertalib/fcrepo4-oaiprovider/builds/94908946
* travis-ci leaves
<ajs6f>acoburn: You cannot use this for the purposes to which we put RdfStreams.
acoburn: topic and stream are _not_ separable. If we did a triplestore/filesystem reimpl, I would use named graphs to persist them, when needed.11:26
<acoburn>ajs6f: so it seems that we need RdfStream to extend Stream<Triple>
ajs6f: along with an implementing class
ajs6f: that requires the topic in the constructor
ajs6f: b/c now, you can create an RdfStream w/o a topic just fine11:27
<ajs6f>acoburn: That would be about my first move, but I don't know that for sure. What I do know is that I would like the identity of SonOfRdfStream to be co-existent with those of the topic _and_ stream.
acoburn: You are right that the constructors currently don't make much sense.
acoburn: History.
acoburn: It is not easy to impl Stream, and you cannot subclass the Java API types.11:29
<acoburn>ajs6f: I don't want to go anywhere near having to implement Stream
<ajs6f>acoburn: In the old Java8 branch, I wrapped a Stream into RdfStream as a private member and forward all Stream API methods into that. It was long, but simple and easy to check.
<acoburn>ajs6f: did you disable parallelism on the stream methods?11:30
<ajs6f>acoburn: I cannot remember. I think I did something trickier. I had an abstract SpliteratorSupportedStream class that wrapped a Spliterator and RdfStream was a subclass of that. So it was really Spliterator.Characteristics that mattered.11:31
* dhlamb leaves
<ajs6f>acoburn: But that all may have been a bad idea. For all I know you may have the right idea now. I don't understand any of this computer crap anyway.11:32
afk bbl
* ajs6f leaves
* billmcm leaves11:36
* peichman leaves11:48
* escowles leaves11:59
* github-ff joins12:05
[fcrepo-camel] mikedurbin opened pull request #99: Extracted generic fedora client code. (master...FCREPO-1815) http://git.io/vR8HQ
* github-ff leaves
<mikeAtUVa>awoods: I think I'll need to get fcrepo-java-client into the snapshots repo before the fcrepo-camel PR will build... could you point me to documentation on how to set that up?12:06
<awoods>mikeAtUVa: jenkins does that for us...12:15
mikeAtUVa: I can get fcrepo-java-client (if it is ready) into jenkins later this afternoon12:16
mikeAtUVa: I am stepping out for a moment now... then meetings until 4:30ET
<mikeAtUVa>awoods: I think it's ready, it certainly builds and I didn't change any code (except package names) from the original files in fcrepo-camel.12:17
awoods: if you get a chance, that'd be great!
* ajs6f joins12:18
* dhlamb joins12:26
<ajs6f>acoburn: Do you see what I mean about a "shell"? This is what I was getting at with my maundering on about identity.12:28
<acoburn>ajs6f: yes, and I completely agree12:34
<ajs6f>acoburn: Then you better check your head
acoburn: Agreement with me is the first sign of a concussion.
<acoburn>ajs6f: the issue is with the Stream holding state.12:35
<ajs6f>acoburn: A pure Stream certainly should not. But why couldn't a subclass hold state?12:36
<acoburn>ajs6f: so a interfact RdfStream extends Stream<Triple>
ajs6f: and some implementing class12:37
ajs6f: which holds that state
s/interfact/interface
<ajs6f>interface RdfStream extends Stream<Triple> { Node topic(); }
<acoburn>exactly
<ajs6f>acoburn: i would not pretend for a moment that doing that impl is going to be fun. I do think there is one advantage: that design explains where to move from kernel to impl (e.g. -modeshape).12:38
acoburn: The interface is kernel, each new kernel impl offers a new impl. E.g. the -modeshape one might feature Session session(), but a hypothetical Hadoop one wouldn't12:39
<acoburn>ajs6f: so you would expect the implementing class would be in -kernel-modeshape (or -kernel-hadoop, etc)12:40
<ajs6f>acoburn: Yes. An RdfStream impl (and any needed supporting machinery) captures the heart of the mapping from the Fedora API to and from some concrete technology that is supporting it. In the case of MODE, that concrete tech is JCR, represented conveniently enough by the type Session.12:41
<acoburn>ajs6f: that works for me12:42
* dwilcox leaves12:46
* billmcm joins12:47
<ajs6f>acoburn: Okay. I guess that solves all the problems, then.12:49
<acoburn>ajs6f: there's still the small matter of implementing this, but it is a step in the right direction12:50
* dwilcox joins12:56
* jgpawletko joins
* peichman joins12:58
<whikloj>ajs6f: I saw a rumour somewhere that you may have produced another human, is that correct?13:04
<ajs6f>acoburn: impl shmimpl.
whikloj: No, that would be front page news all around the world. It was my wife who accomplished that feat, with marvelous presence of mind and a remarkable degree of grace.13:06
* ajs6f leaves
* escowles joins13:14
* escowles leaves13:30
* escowles joins13:51
* escowles leaves13:55
* escowles joins14:04
* dhlamb_ joins14:16
* dhlamb leaves
* jrgriffiniii joins14:19
* escowles leaves14:20
* peichman leaves14:34
* peichman joins14:35
* jrgriffiniii leaves14:37
* jrgriffiniii joins14:41
* jrgriffiniii leaves15:04
* jrgriffiniii joins15:05
* dhlamb_ leaves15:15
* escowles joins15:18
* escowles leaves15:22
* jgpawletko leaves16:17
* dwilcox leaves16:41
* acoburn leaves16:51
* billmcm leaves16:58
* mikeAtUVa leaves17:03
* jrgriffiniii leaves17:10
* peichman leaves17:13
* whikloj leaves18:00
<f4jenkins>Project fcrepo-java-client build #1: SUCCESS in 50 sec: http://jenkins.fcrepo.org/job/fcrepo-java-client/1/18:09
* travis-ci joins18:13
ualbertalib/fcrepo4-oaiprovider#26 (oai_etdms - 38fb991 : piyapongch): The build passed.
Change view : https://github.com/ualbertalib/fcrepo4-oaiprovider/compare/28f6499ceca2...38fb991c1427
Build details : https://travis-ci.org/ualbertalib/fcrepo4-oaiprovider/builds/94987793
* travis-ci leaves
* github-ff joins18:57
[fcrepo-java-client] awoods pushed 3 new commits to master: http://git.io/vRRIM
fcrepo-java-client/master a0cd9d2 Andrew Woods: Prepare for 0.1.0 release
fcrepo-java-client/master 9856008 Andrew Woods: [maven-release-plugin] prepare release fcrepo-java-client-0.1.0
fcrepo-java-client/master 19c0774 Andrew Woods: [maven-release-plugin] prepare for next development iteration
* github-ff leaves
* github-ff joins18:58
[fcrepo-java-client] awoods tagged fcrepo-java-client-0.1.0 at 7237987: http://git.io/vRRIS
* github-ff leaves
* github-ff joins19:26
[fcrepo-java-client] awoods created gh-pages (+1 new commit): http://git.io/vRR3E
fcrepo-java-client/gh-pages e0fdc20 Andrew Woods: Creating site for fcrepo-java-client, 0.1.0
* github-ff leaves
* github-ff joins19:31
[fcrepo-camel] awoods pushed 1 new commit to master: http://git.io/vRRso
fcrepo-camel/master 1695a1d Mike Durbin: Extract generic fedora client code....
* github-ff leaves
* travis-ci joins19:34
fcrepo4-exts/fcrepo-camel#238 (master - 1695a1d : Mike Durbin): The build passed.
Change view : https://github.com/fcrepo4-exts/fcrepo-camel/compare/aa18cd53119d...1695a1d51d35
Build details : https://travis-ci.org/fcrepo4-exts/fcrepo-camel/builds/94998982
* travis-ci leaves
* peichman joins20:04
* peichman leaves20:10
* peichman joins
* peichman leaves20:11
* peichman joins20:45
* peichman leaves21:06
* peichman joins22:14
* peichman leaves22:26
* peichman joins22:56
* peichman leaves22:59