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

Using timezone: Eastern Standard Time
* manez joins04:29
* manez leaves04:33
* manez joins05:29
* manez leaves05:34
* manez joins06:30
* manez leaves06:35
* manez joins07:31
* manez leaves07:36
* dwilcox joins07:51
* manez joins08:00
* manez leaves08:30
* manez joins08:34
* jjtuttle joins08:36
* whikloj joins08:51
* coblej joins09:03
* coblej leaves09:18
* coblej joins
* acoburn joins09:30
* dbernstein joins
* mohamedar joins09:31
* awoods joins09:35
* ajs6f joins09:39
* peichman joins
* coblej leaves09:40
* amccarty joins
* amccarty leaves
* amccarty joins
<acoburn>awoods: question about registered namespaces — couldn't we just filter out the MODE and JCR namespaces, since we're already filtering out any such triples?09:41
awoods: likewise for the test: namespace — that doesn't seem to belong
* coblej joins09:42
* amccarty_ joins
<awoods>acoburn: both suggestions sound right.
<acoburn>awoods: is there an existing ticket for this? Or, I can create one
<awoods>acoburn: please create it09:43
acoburn: We use "test" in our tests...
acoburn: you are just talking about filtering the namespace from responses?
<acoburn>awoods: yes, from the responses09:44
<awoods>acoburn: ok
<acoburn>awoods: i.e. here: https://github.com/fcrepo4/fcrepo4/blob/master/fcrepo-kernel-modeshape/src/main/java/org/fcrepo/kernel/modeshape/utils/NamespaceTools.java#L9909:45
* amccarty leaves09:46
<acoburn>awoods: https://jira.duraspace.org/browse/FCREPO-224409:47
awoods: we can deal with test: separately
<awoods>acoburn: Having specific, singular tickets is good. Thanks.09:48
<ruebot>awoods, acoburn: somewhat related question, I was going through old mailing list threads, and I'm looking for a community suggested/preferred way of registering prefixes on repository initialization. does such a thing exist?09:50
* ruebot will need to do this for NYC Camp fcrepo-vagrant, and CLAW
<acoburn>ruebot: I just create a test resource that uses the various namespaces09:51
ruebot: I also wrote a utility that can modify certain namespaces, but peichman reported that it corrupted his dev repo, so I'm a little reluctant to recommend it09:52
<ruebot>acoburn: cool. i was using awead's method that creates a resource, and deletes it and the tombstone for it.
acoburn: yeah, i remember that one from the thread too.
<awoods>ruebot: acoburn's suggestion is the way we would like users to do this... but you can also simply add those namespaces to the cnd file. https://github.com/fcrepo4/fcrepo4/blob/master/fcrepo-kernel-modeshape/src/main/resources/fedora-node-types.cnd#L2909:53
<ruebot>awoods: yeah, that was the other method i was looking at, but it seemed frowned upon.09:54
<awoods>ruebot: exactly
<acoburn>awoods: isn't it possible to add a secondary CND file in the repository.json configuration?
<awoods>acoburn: sure, you can have multiple cnd files
<acoburn>awoods: i.e. … "node-types" : ["fedora-node-types.cnd", "file:/my/cnd/file.cnd"]09:55
awoods: or something like that
* coblej leaves09:59
<peichman>acoburn: multiple CND files definitely sounds like a better way to set up prefixes than having to initialize the repo with a dummy resource
<acoburn>peichman: yes, I agree10:00
<ruebot>acoburn, awoods, peichman: i'll work on a proof-of-concept for CLAW, and y'all like it, I can add it to fcrepo-vagrant.
* ruebot disappears for a bit
* mohamedar1 joins
* coblej joins10:03
* mohamedar leaves10:04
* bseeger joins10:18
* mikeAtUVa joins10:26
<ajs6f>You got to do what you got to do. The thing that is ugly about CND is that it's totally JCR specific. We should probably think about a more elegant long-term solution for prefix management.10:31
* github-ff joins
[fcrepo4] acoburn opened pull request #1105: Exclude internal (jcr, mode) prefixes from namespace map (master...fcrepo-2244) https://git.io/vPefx
* github-ff leaves
<whikloj>awoods: I'm building the RC-1 and I realized I named the branch 4.7.0-RC-1 in rbacl. Do you think it is better or worse to push a new branch, re-tag it and delete the old one.10:33
or leave it alone
<awoods>whikloj: can you just rename the branch?10:34
<bseeger>awoods: yes to a new Jira ticket for managing integration of Josh's and my code. Should I just go ahead and create it?
<whikloj>awoods: I'm unclear how that works when I push that change to origin?10:35
<awoods>whikloj: https://gist.github.com/lttlrck/9628955
<whikloj>awoods++ # Here goes nothing10:36
* github-ff joins10:37
[fcrepo-module-auth-rbacl] whikloj deleted 4.7.0-RC-1 at 46891e9: https://git.io/vPeJN
* github-ff leaves
* github-ff joins
[fcrepo-module-auth-rbacl] whikloj created 4.7.0-RC at 46891e9 (+0 new commits): https://git.io/vPeJj
* github-ff leaves
<awoods>whikloj: what commands did you use?10:38
<whikloj>awoods: I used the ones in that gist
<awoods>whikloj: ok
<whikloj>awoods: It moves/renames is locally, but you delete and re-push the remote branch
...renames it locally...10:39
* mohamedar joins10:40
<whikloj>ie. https://gist.github.com/lttlrck/9628955#gistcomment-1562089
* mohamedar1 leaves10:41
<acoburn>awoods: ajs6f: is there a plan to publish this: https://github.com/fcrepo4/fcrepo4/blob/master/fcrepo-kernel-modeshape/src/main/resources/fedora-node-types.cnd#L3510:42
<ajs6f>acoburn: No idea. Do we actually use that?10:43
<acoburn>awoods: ajs6f: it's used to define the DEFAULT_DIGEST_ALGORITHM
<ajs6f>Okay, then.
We should probably get it out there, I guess.
<acoburn>ajs6f: unless you want that property (fedoraconfig:defaultDigestAlgorithm) to go into the main fedora ontology10:44
<ajs6f>acoburn: NO. Definitely not.10:45
* travis-ci joins
<acoburn>ajs6f: then it should be published separately. fine with me
<travis-ci>fcrepo4/fcrepo-module-auth-rbacl#89 (4.7.0-RC - 46891e9 : Aaron Coburn): The build passed.
Change view : https://github.com/fcrepo4/fcrepo-module-auth-rbacl/compare/4.7.0-RC
Build details : https://travis-ci.org/fcrepo4/fcrepo-module-auth-rbacl/builds/163117535
* travis-ci leaves
<ajs6f>Actually, I'm not even sure now that we should publish it in the same way. It's impl-specific, so maybe it hould go in the docs for the impl.10:46
<acoburn>ajs6f: maybe the namespace shouldn't be dereferenceable: i.e. <info:fedoraconfig/>10:47
<ajs6f>acoburn: yeah, I can see that. There is no obvious value to an actual ontology behind that.10:48
<awoods>acoburn: non-dereferenceable <info:fedoraconfig/> sounds good.10:54
<ajs6f>Maybe we should just make everything non-dereferencable. Just back away from the whole Linked Data thing.10:55
* cmmills joins10:56
<acoburn>awoods: https://jira.duraspace.org/browse/FCREPO-224710:59
<awoods>acoburn: Could you please add a desired outcome or considerations of the "review" mentioned in: https://jira.duraspace.org/browse/FCREPO-224711:00
<acoburn>awoods: better?11:03
<awoods>acoburn: thanks11:05
<acoburn>ajs6f: btw, w/r/t COPY on the root, what I noticed was this:11:06
ajs6f: say you copy the root (/rest) to /rest/newroot
ajs6f: now when you request /rest/newroot, you get the same response as you do with /rest (i.e. the SAME SUBJECT)11:07
* mjgiarlo leaves
<ajs6f>acoburn: I didn't see that. But I saw several different kinds of behavior is several different tries.
acoburn Neither predictable nor useful.11:08
<acoburn>ajs6f: I agree
* mjgiarlo joins11:11
* github-ff joins11:12
[fcrepo4] acoburn opened pull request #1106: Remove test: namespace from the modeshape config (master...fcrepo-2247) https://git.io/vPetx
* github-ff leaves
* coblej leaves11:24
* coblej joins11:30
<ajs6f>acoburn:awoods: https://lists.w3.org/Archives/Public/public-ldp/2016Sep/0000.html11:31
Have we come to any conclusion on LDN?
<acoburn>ajs6f: I like it
<acoburn>ajs6f: I've been following the github discussions11:32
ajs6f: I made a minor suggestion to their spec so that Fedora can be used as a "receiver" w/o modification
ajs6f: they accepted the suggestion
<ajs6f>Cool. So we're already implementing it. That's the story, right?11:33
<acoburn>ajs6f: I'm planning to write a camel-based connector that plugs into the event stream
ajs6f: as a receiver, yes
* coblej leaves11:35
* mohamedar leaves11:36
* coblej joins11:37
<acoburn>ajs6f: how much do you want these values to be constants? https://github.com/fcrepo4/fcrepo4/pull/1104 (PUT, POST, OPTIONS, etc)11:38
<ajs6f> acoburn: It'd be nice. It would make things a bit clearer. Is it a big deal?11:40
<acoburn>ajs6f: it's fine, it just requires a lot more keystrokes (HttpMethods.DELETE)
* coblej_ joins11:41
* coblej leaves
<ajs6f>acoburn: Wait, what? I'm thinking two constants— one for "things you can do to the root" and one for "things you can do for anything". What are you thinking of?
<acoburn>ajs6f: but there's also what you can do for Binaries and Binary Descriptions11:42
ajs6f: and those are all different sets
<ajs6f>acoburn: Okay, that sounds like an EnumMap<ResourceType, Set<HttpMethods>>11:43
<amccarty_>morning folks - qq about fcrepo backup/restore (https://wiki.duraspace.org/display/FEDORA4x/Backup+and+Restore): if I'm using mysql or postgres, I need to backup/restore that data separately, correct?
<acoburn>ajs6f: https://github.com/fcrepo4/fcrepo4/blob/master/fcrepo-http-api/src/main/java/org/fcrepo/http/api/FedoraLdp.java#L607-L616
<ajs6f>acoburn: No enum? Okay, Map<? extends FedoraResource, Set<HttpMethods>>11:45
Oops, I mean Map<Class<? extends FedoraResource>, Set<HttpMethods>>
<acoburn>ajs6f: sort of — the test for repo-root is a little different
ajs6f: so you can't just do a simple Map::get
* coblej_ leaves
<ajs6f>acoburn: Is that by Modeshape-specific JCR nodetype?
<acoburn>ajs6f: sort of, but this is for the HTTP layer, and the mode:root type has already been filtered out11:46
* bseeger leaves
<ajs6f>acoburn: How is it tested?
<acoburn>ajs6f: if (resource.getContainer() == null)11:47
* coblej joins
<acoburn>amccarty_ no, that data is part of the JCR export, no need to back it up separately
amccarty_ but backing it up would be a good idea IMO
<ajs6f>acoburn: That's kind of weak, and worse, if we allow uncontained PUTs, that will break
<amccarty>acoburn: cool - thanks11:48
<acoburn>amccarty_ this allows you do do things like export from a levelDB backend into a postgres DB
<ajs6f>acoburn: If you have an uncontained PUT-created resource in the middle of the repo (URI-space-wise), you should be able to delete it.11:49
<acoburn>ajs6f: then maybe we should just leave things as they are
<amccarty>acoburn: ah - that makes sense. I think I'll go with FS backup for now, but I did try the restore just now and it started off successfully, but died with this message: "java.sql.BatchUpdateException: Duplicate entry '2b3ad19317f1e7jcr:system/mode:metadata' for key 'PRIMARY'"
I can create an issue if that helps.
<acoburn>ajs6f: if there are multiple root resources, then MOVE/DELETE _would_ be permitted11:50
ajs6f: which means that the Allow methods would be the same on the root as they would for any arbitrary container
<ajs6f>acoburn: Yeah, that's what I am thinking. And I am also inclined to think that there will be MRR eventually.11:51
<acoburn>ajs6f: yes, I'd like to see that, too.
ajs6f: then I'll close the PR
<ajs6f>acoburn: Close it like a bear trap!
* github-ff joins11:52
[fcrepo4] acoburn closed pull request #1104: Remove DELETE/MOVE methods from Allow header on RepositoryRoot resources (master...fcrepo-2158) https://git.io/vih8L
* github-ff leaves
* coblej leaves
* coblej joins11:53
* coblej leaves11:58
* coblej joins11:59
* ajs6f leaves12:00
* coblej leaves12:04
* coblej joins12:05
* mjgiarlo leaves12:17
* mjgiarlo joins12:18