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

Using timezone: Eastern Standard Time
* dwilcox joins07:34
* dwilcox leaves08:14
* dwilcox_ joins
* mhwood joins08:16
* dwilcox joins08:18
* dwilcox_ leaves
* anarchivist leaves08:27
* anarchivist joins
* awead joins08:31
* escowles joins08:32
* dhlamb joins08:39
* ksclarke leaves08:53
* jrgriffiniii joins09:12
* acoburn joins09:15
* awoods joins09:26
* escowles leaves09:35
* whikloj joins09:56
* ksclarke joins09:57
<acoburn>awoods: ping10:04
<acoburn>awoods: question about the (tripartite) github module structure
<awoods>acoburn: ok
<acoburn>awoods: first, would smth like fcr-transform be outside of core?10:07
awoods: it seems non-core to me
<awoods>acoburn: fcr-transform is not a separate project
<acoburn>awoods: ok, what about fcr-audit
<awoods>acoburn: The question is, what are the F4 core features.10:08
acoburn: we need to establish consensus on the answer.
<acoburn>awoods: so my question is actually not so much a theoretical one, but a very practical one10:09
awoods: say there is an extension module (e.g. fcr-audit)
<awoods>acoburn: whatever the answer is, those are the projects that will reside in the fcrepo4 github organization.
acoburn: ok
<acoburn>awoods: how would, then, one build a warfile with that optional dependency?
if we use profiles, we still need the fcr-webapp module to depend on the non-core feature in the build defn10:10
<awoods>acoburn: presumably with fcrepo-webapp-plus... or better yet, osgi.
<acoburn>awoods: yes, absolutely use OSGi, but we're not there yet
<awoods>acoburn: fcrepo-webapp-plus fills this role.
acoburn: no?
<acoburn>awoods: so the idea is to have two webapp projects? (as is currently the case) That seems confusing10:11
<awoods>acoburn: suggestions?
<acoburn>awoods: pull the webapp module out of fcr-core10:12
awoods: then you have only one module building a war file
<awoods>acoburn: That is an interesting idea, that would be a part of the consensus building mentioned above.10:13
<acoburn>awoods: that would reside in the fcr-ext (or whatever the name is) github repo, with all the relevant profiles defined
awoods: this also separates the deployment machinery from the api specification
<whikloj>acoburn: do we lose anything with your suggestion?10:14
<awoods>acoburn: Since Fedora is moving towards a being defined by a set of RESTful services, it may be a highly debatable argument to remove the webapp, but a debate worth having.
<acoburn>awoods: I'm just seeing a lot of different types of JVM deployment strategies out there now: containerless (a-la dropwizard), osgi (karaf) and of course tomcat/jetty10:16
<awoods>acoburn: Can you have a "reference implementation" of RESTful services with out a webapp?10:17
<acoburn>awoods: that's a good question
awoods: I'd think you'd still need a deployable implementation10:18
* mikeAtUVa joins
<acoburn>awoods: the thrust of my argument, though, is that by leaving the fcr-webapp in place, we would need multiple fcr-webapp-like modules: one for core-only and one for everything else10:19
awoods: otherwise you end up with the webapp (in core) depending on non-core (optional) modules
<awoods>acoburn: currently we have a barebones deployable implementation (fcrepo-webapp) that just contains "core" features. We also have a deployable implementation that can be configured to contain optional capabilities (fcrepo-webapp-plus).10:20
<acoburn>awoods: I guess the question is: is that structure adequately clear to people?
awoods: or, another way to put it: do adopters see an implied difference b/t the webapp in -labs and the webapp in -core10:22
* awoods_ joins
acoburn: There is also a question of whether "maven profiles" really the way we want to enable configuration?
* awoods_ leaves10:23
* awoods_ joins
* awoods_ leaves10:24
<acoburn>awoods: ok, it seems that there are a number of open questions10:25
* awoods leaves10:26
<acoburn>whikloj: back to your question (whether we lose anything with this suggestion)10:29
whikloj: I think it comes down to how we define what belongs in a reference impl
whikloj: there is a compelling argument to be made that the ref impl should be deployable10:30
whikloj: and an equally compelling one to be made that the ref impl shouldn't be tied to a particular deployment strategy
<whikloj>acoburn: I like the former, but I think the latter is better. So if we don't tie to a single strategy, but provide guidance on the various options.10:33
* awoods joins10:35
<acoburn>whikloj: that's exactly my thought10:36
<awoods>acoburn: can you add the topic to the Thursday agenda?10:37
<acoburn>awoods: sure thing
<whikloj>acoburn: so when you are talking about splitting the webapp out of "core", would it be replaced by a variety of "webapp"-like fcrepo-ext modules?10:39
acoburn: one that works in tomcat/jetty, one for an OSGI container, etc, etc10:40
<acoburn>whikloj: basically, yes. The idea is that there wouldn't be two different webapp modules (one for core-only; one for everything else)10:41
* mhwood leaves10:45
<whikloj>acoburn: ok, cool. I don't think I fully understand it, but I'm closer.
<f4jenkins>Yippee, build fixed!10:52
Project fcrepo4-T2 build #284: FIXED in 4 min 55 sec: http://jenkins.fcrepo.org/job/fcrepo4-T2/284/
<acoburn>awoods: another question about the github organization11:10
awoods: has there been any discussion of moving the core api (e.g. fcrepo-kernel) into its own repository?
awoods: possibly versioned separately from the ref impl?11:11
<awoods>acoburn: There have been related discussions...
acoburn: around making the "core" ref impl as small as possible11:12
acoburn: and versioning it separately from the "Fedora API"
<acoburn>that would be nice11:13
<awoods>acoburn: The "Fedora API" will be defined as a RESTful API, not what we currently see in fcrepo-kernel
<acoburn>awoods: so the ref impl is more like fcrepo-http-api11:14
<awoods>acoburn: The idea is that F4 should be defined by a clear, testable set of RESTful APIs
acoburn: correct
acoburn: if someone where to be interested in putting a completely different impl under the "Fedora <RESTful> API", that should be completely possible.11:15
acoburn: and verifiable with Fedora TCKs
<acoburn>awoods: and in an ideal world the existing test suite would be its own project that could be used to test such impls11:16
<awoods>acoburn: yes and no. A proper TCK would need to be written from scratch that tests a yet undefined Fedora API. But yes, it would be its own project.11:17
<acoburn>awoods: it would also be an opportunity to deal with gaps in test coverage11:18
<awoods>acoburn: absolutely. Teasing out core from optional, creating github organizations as appropriate, defining the F4 API and associated TCKs... this is a critical transition for F4.11:20
* ajs6f joins11:25
* ajs6f1 joins11:33
* ajs6f leaves11:36
<acoburn>awoods: sorry to bother you again…11:38
awoods: an OSGi question
as you know, fcrepo-kernel-impl breaks through the modeshape layer to access non-public APIs11:39
there are five times this is done in the code
I have eliminated four of these in a local branch
the last one, though is a bit complicated
<awoods>acoburn: ok11:40
<acoburn>the issue is that there seemed to be a desire to do distributed fixity checks across an ispn grid for binary files
<awoods>acoburn: yes11:42
<acoburn>awoods: if we just use the modeshape public api, we can't do distributed execution of fixity (just fixity for a single iostream)
awoods: doing so would also remove hundreds of lines of code
<awoods>acoburn: so you are wondering if we should remove the ability for F4 to perform distributed execution of fixity over an ISPN grid?11:43
<acoburn>awoods: yes. the current (default) mode/ispn configs don't include support for an ispn grid from binary files11:44
awoods: if that capability is desired, it is possible to hook into the ispn grid independent of modeshape11:45
<awoods>acoburn: Really?
<acoburn>awoods: I think so (though I'm not entirely certain)11:46
<ajs6f1>acoburn: Really?
<awoods>acoburn: You have a pathway for circumventing ModeShape to interact with ISPN?
acoburn: in a "safe" way?
<acoburn>awoods/ajs6f1: that's the question — basically getting around all of these modeshape hacks is to pull the RepositoryConfiguration from the running JcrRepository object11:47
and then make decisions about the underlying storage system based on those values
* ajs6f1 leaves11:48
* ajs6f1 joins
acoburn: I don't understand that. Is there a reference to ISPN objects in a RepositoryConfiguration?11:49
<acoburn>awoods/ajs6f1: The modeshape configuration gives you all the values for the ISPN config11:50
<awoods>acoburn: The fact is, no one has used an ISPN configuration that uses distributed fixity in probably two years.
<acoburn>awoods: right, and that's why I'm wondering about ripping that out entirely.
<ajs6f1>awoods: Maybe run it past the email lists with an assumption that unless someone speaks up, we drown it in a bucket?
A bucket of vegetable oil.11:51
<acoburn>awoods: if we can remove it, this becomes an easy task
<awoods>acoburn: barmintor is the one who is probably most vested.
<ajs6f1>acoburn/awoods: Distributed fxity was definitely the reason that barmintor and cbeer did this to begin with.
<acoburn>awoods/ajs6f1: if we can't remove it, it may not be an easy task, though it might be possible to move that code to an extension module11:52
before I left on vacation, I did some thread-pulling that lead me to a point where it seemed possible to deal with (using only public APIs)11:53
<awoods>acoburn: Given the relative importance of OSGi over distributed fixity execution, I would support gutting it. But a note to the list is always a good idea.
<acoburn>OK, I'll ask on the list11:54
<awoods>acoburn: ...at least the fedora-committers list
acoburn: I am not sure anyone else has more than a theoretical idea of what you would be talking about... and it would likely just scare people.11:55
<acoburn>awoods: that makes sense to me.
<ajs6f1>Fedora scares people.11:56
<acoburn>that said, if anyone here is not on the committer list (esp: whikloj) would like to be part of the discussion, I'd be happy to include them.11:57
I don't want to scare anyone, but I also don't think it needs to be secret
<ajs6f1>"We want to remove a feature you didn't know about so that we can fulfill a technical criterion you don't want to know about."11:58
<whikloj>acoburn: thanks, but I think this may be way over my head and I agree with awoods that it would likely scare people.
<whikloj>also acoburn++
<ajs6f1>Indeed, thanks for seeing this through, acoburn.
<whikloj>I don't even truly understand what acoburn has done so I can't give it the true awe it probably deserves12:01
* ajs6f1 leaves12:04
* github-ff joins12:37
[fcrepo4] escowles pushed 1 new commit to fcrepo-1532: http://git.io/vqC7E
fcrepo4/fcrepo-1532 3b6464d Esmé Cowles: Using ebucore:hasMimeType and ebucore:filename instead of jcr/fedora:mimeType and premis:hasOriginalName
* github-ff leaves
* bseeger joins12:40
* dwilcox leaves12:58
* awoods_ joins
* awoods_ leaves
* awoods_ joins12:59
* awoods_ leaves
* awoods leaves13:01
* awoods joins13:09
* dwilcox joins13:41
<awoods>acoburn: is there a test that verifies the distributed fixity execution?13:47
<acoburn>awoods: not that I know of, but I'll check
<awoods>acoburn: If you were to remove the functional logic and no tests break... than I am not sure how much value there is in migrating the functionality to a labs project.13:48
acoburn: ...because there would not be an existing way of verifying that it even works.13:49
<acoburn>awoods: well the distributed execution code is covered in some of the tests, but AFAIK, it only uses a single ISPN cache, so it isn't really testing a distributed architecture13:50
<awoods>acoburn: hmm. What are your thoughts? rely on the version history or extract out the functionality into a separate project?13:54
<acoburn>awoods: in fcrepo-kernel-impl there is an ISPN config that stores the binaries in a cache (rather than on the FS), but it only uses a single cache store13:55
<acoburn>awoods: so the "distributed" features aren't tested (not even as a pseudo-distributed environment)
<awoods>not surprising.
acoburn: so what is your opinion on the question above?
<acoburn>awoods: I think there is value in having a fcrepo-infinispan module in -labs that exposes some of the underlying ISPN features13:57
<awoods>acoburn: "exposes some of the underlying ISPN features"... meaning a project that has even larger scope than the distributed execution functionality?13:58
<acoburn>awoods: yes. if it's possible to access the caches as I described (which remains to be confirmed in practice), then all sorts of options become possible (think what HDFS allows in terms of MapReduce; the same is true for ISPN, but it's not currently accessible)13:59
<awoods>acoburn: If you think the creation of a new project starting with the distributed ISPN execution is reasonable, that would be good... otherwise, simply gutting the functionality is also an option. How would you like to proceed?14:17
<acoburn>awoods: that is correct. this MODE config tests an ISPN binary cache: https://github.com/fcrepo4/fcrepo4/blob/master/fcrepo-http-api/src/test/resources/test_repository.json14:20
awoods: which references this ISPN config: https://github.com/fcrepo4/fcrepo4/blob/master/fcrepo-kernel-impl/src/test/resources/config/testing/infinispan-basic.xml14:21
awoods: there are three namedCache defns, but it seems that there's only a single binary store14:22
awoods: as to your question ^^^^, it would be a lot easier to just gut the functionality14:23
* pgwillia joins14:25
<acoburn>awoods: specifically, I'd like to (1) remove the relevant classes from fcrepo-kernel-impl and (2) put those files somewhere for safe keeping.
* bseeger leaves
<acoburn>awoods: then, if there is interest, we can organize those files into an extension module
awoods: but I would emphasize that my primary interest here is in the architectural integrity of fcrepo-kernel-impl, not in exposing ISPN features14:30
awoods: if the latter happens at all, it would be much farther down the road (unless someone else steps up to implement this)14:31
<awoods>acoburn: but the first task would be to extract the distributed functionality and tests into a new github/maven project that minimally builds.14:32
<acoburn>awoods: you mean before removing those features from fcrepo-kernel-impl?14:33
awoods: I don't want that to be a blocker, as I'm not entirely certain that it is possible14:34
<awoods>acoburn: I was meaning that the code be pulled from fcrepo-kernel-impl and moved into this new project... lunch is ready.14:35
<acoburn>awoods: ok, I think we're talking about exactly the same thing14:40
* dwilcox leaves14:42
* dwilcox_ joins
acoburn: Would you be willing to remove the functionality and create a follow-on ticket for creating a labs project from the removed source?15:01
<acoburn>awoods: will do
<awoods>acoburn: thanks15:02
<acoburn>awoods: another topic: I'm +1 on all the https://jira.duraspace.org/browse/FCREPO-1552 related PRs
awoods: shall I merge them?
<awoods>acoburn: squash and merge as appropriate. thanks.15:03
* ajs6f joins15:13
* ajs6f1 joins15:15
* ajs6f leaves
* github-ff joins15:28
[fcrepo4] acoburn pushed 3 new commits to master: http://git.io/vqlTS
fcrepo4/master 3932771 yinlinchen: remove fedora:uuid...
fcrepo4/master cc610c6 Andrew Woods: Update names of default transform fields...
fcrepo4/master 3908141 Aaron Coburn: Merge branch 'yinlinchen-fcrepo-1552'
* github-ff leaves
* github-ff joins
[fcrepo4] acoburn closed pull request #804: remove fedora:uuid (master...fcrepo-1552) http://git.io/vkn2A
* github-ff leaves
* github-ff joins15:29
[fcrepo-message-consumer] acoburn pushed 2 new commits to master: http://git.io/vqlkW
fcrepo-message-consumer/master 41f2458 Andrew Woods: Update test schema.xml due to impact of updated transform...
fcrepo-message-consumer/master 2326a82 Aaron Coburn: Merge pull request #85 from awoods/fcrepo-1552...
* github-ff leaves
* github-ff joins15:34
[fcrepo-camel] acoburn pushed 2 new commits to master: http://git.io/vqlLd
fcrepo-camel/master 3b23c53 Yinlin Chen: Resolves: https://jira.duraspace.org/browse/FCREPO-1552
fcrepo-camel/master 6ee5c26 Aaron Coburn: Merge pull request #72 from yinlinchen/fcrepo-1552
* github-ff leaves
* github-ff joins15:35
[fcrepo-camel] acoburn closed pull request #72: Resolves: https://jira.duraspace.org/browse/FCREPO-1552 (master...fcrepo-1552) http://git.io/vIUOv
* github-ff leaves
* mikeAtUVa leaves15:37
* dwilcox_ leaves15:41
* travis-ci joins15:44
fcrepo4/fcrepo-message-consumer#140 (master - 2326a82 : Aaron Coburn): The build passed.
Change view : https://github.com/fcrepo4/fcrepo-message-consumer/compare/98b695371548...2326a820503a
Build details : https://travis-ci.org/fcrepo4/fcrepo-message-consumer/builds/69783995
* travis-ci leaves
* travis-ci joins15:45
fcrepo4/fcrepo-camel#189 (master - 6ee5c26 : Aaron Coburn): The build passed.
Change view : https://github.com/fcrepo4/fcrepo-camel/compare/0470bd508b12...6ee5c2663d9a
Build details : https://travis-ci.org/fcrepo4/fcrepo-camel/builds/69784763
* travis-ci leaves
* github-ff joins15:47
[fcrepo-camel-toolbox] acoburn pushed 3 new commits to master: http://git.io/vqlsu
fcrepo-camel-toolbox/master 8200073 Yinlin Chen: Resolves: https://jira.duraspace.org/browse/FCREPO-1552
fcrepo-camel-toolbox/master 304692a Andrew Woods: Update test schema.xml due to impact of updated transform...
fcrepo-camel-toolbox/master 45aebe5 Aaron Coburn: Merge pull request #32 from yinlinchen/fcrepo-1552...
* github-ff leaves
* github-ff joins
[fcrepo-camel-toolbox] acoburn closed pull request #32: Resolves: https://jira.duraspace.org/browse/FCREPO-1552 (master...fcrepo-1552) http://git.io/vIJ6c
* github-ff leaves
* travis-ci joins15:55
fcrepo4/fcrepo4#3797 (master - 3908141 : Aaron Coburn): The build passed.
Change view : https://github.com/fcrepo4/fcrepo4/compare/50b639c55ca0...3908141a1879
Build details : https://travis-ci.org/fcrepo4/fcrepo4/builds/69783788
* travis-ci leaves
* travis-ci joins15:59
fcrepo4-labs/fcrepo-camel-toolbox#109 (master - 45aebe5 : Aaron Coburn): The build passed.
Change view : https://github.com/fcrepo4-labs/fcrepo-camel-toolbox/compare/c60d353f61d9...45aebe5d2205
Build details : https://travis-ci.org/fcrepo4-labs/fcrepo-camel-toolbox/builds/69786668
* travis-ci leaves
<whikloj>awoods: ping16:03
<whikloj>awoods: re FCREPO-1614, is it really a constraint that you can't apply RDF with a made-up subject?
<awoods>whikloj: my concern is more around not wanting any more data URIs.16:06
whikloj: The scenario in that ticket exposes a scenario where a data URI comes back in the link header.
<whikloj>awoods: ok, so here are the 3 options I see. 1) Remove the whole data URI creation, 2) Create a new exception for imaginary subjects, 3) Make the existing PathNotFoundException a sub-class of ConstraintViolationException16:07
awoods: kind of depends on whether it is a constraint or we just want to stop pushing out data URIs16:08
<ajs6f1>whikloj: PathNotFoundException isn't ours, it belongs to JCR.
<awoods>whikloj: F4 does indeed have the constraint that you can not push RDF with made-up subjects.
* dhlamb leaves16:09
<whikloj>awoods: true but we have this https://github.com/fcrepo4/fcrepo4/blob/master/fcrepo-kernel/src/main/java/org/fcrepo/kernel/exception/PathNotFoundRuntimeException.java
<awoods>whikloj: so maybe option #2?
<ajs6f1>whikloj/awoods: #2++16:10
<whikloj>awoods/ajs6f1: What would this cover, RDF that has a subject that while appearing in domain is not an actual resource?
<awoods>whikloj: yes, like the example in the ticket.16:11
<whikloj>awoods: ok just saw we have a PathNotFoundException and wondered if that would be the correct thing to throw (slightly modified of course)16:12
<awoods>whikloj: It probably depends on the context. I suspect that not everytime a PathNotFoundException is caught at the top-level of the application will it we mapped to a ConstraintException.16:14
<whikloj>awoods: ok, it appears that PathNotFoundRuntime is mostly when getting properties and binary content. I'll make a new exception.16:15
* awead leaves16:20
* awead joins
* awead leaves16:47
* pgwillia leaves16:58
* jrgriffiniii leaves17:05
* acoburn leaves17:57
* whikloj leaves
* ksclarke leaves18:17
* ajs6f1 leaves18:26
* awead joins20:05
* github-ff joins20:36
[fcrepo4] awoods opened pull request #830: Remove fedora:hasNodeType triples from root description (master...fcrepo-1617) http://git.io/vq8MV
* github-ff leaves
* awead leaves21:49
* awead joins22:23
* awead leaves23:13
* awead joins23:45
* awead leaves23:46

Generated by Sualtam