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

Using timezone: Eastern Standard Time
* mcritchlow joins02:03
* mcritchlow leaves02:08
* rbenji joins02:16
* dwilcox joins03:14
* dwilcox leaves03:16
* dwilcox joins03:17
* petertr7_away leaves04:03
* rbenji leaves
* petertr7_away joins04:07
* dwilcox_ joins04:18
* dwilcox leaves04:22
* dwilcox joins04:36
* dwilcox_ leaves04:40
* tjohnson leaves05:04
* dwilcox_ joins06:35
* dhlamb joins06:36
* dwilcox leaves06:39
* dwilcox joins06:54
* dwilcox_ leaves06:57
* dhlamb leaves07:06
* ruebot_a1ay leaves07:13
* ruebot joins07:14
* ruebot leaves
* ruebot joins
* dwilcox_ joins07:22
* dwilcox leaves07:24
* dwilcox_ leaves07:36
* jcoyne joins08:27
* dhlamb joins08:30
* acoburn joins08:56
* travis-ci joins09:01
fcrepo4-exts/fcrepo-transform#33 (master - 6b38bac : Aaron Coburn): The build passed.
Change view : https://github.com/fcrepo4-exts/fcrepo-transform/compare/d386ac259490...6b38bacf8b00
Build details : https://travis-ci.org/fcrepo4-exts/fcrepo-transform/builds/113201160
* travis-ci leaves
* whikloj joins
* travis-ci joins09:04
fcrepo4-exts/fcrepo-audit#77 (master - ddb3684 : Aaron Coburn): The build passed.
Change view : https://github.com/fcrepo4-exts/fcrepo-audit/compare/c00a95d152be...ddb36844948e
Build details : https://travis-ci.org/fcrepo4-exts/fcrepo-audit/builds/113200777
* travis-ci leaves
* travis-ci joins
fcrepo4/fcrepo-module-auth-webac#106 (master - 32015b3 : Aaron Coburn): The build passed.
Change view : https://github.com/fcrepo4/fcrepo-module-auth-webac/compare/d1c7ba61651e...32015b3f504c
Build details : https://travis-ci.org/fcrepo4/fcrepo-module-auth-webac/builds/113136297
* travis-ci leaves
* rbenji joins
* travis-ci joins09:06
fcrepo4/fcrepo-module-auth-xacml#100 (master - 37d9dd4 : Aaron Coburn): The build passed.
Change view : https://github.com/fcrepo4/fcrepo-module-auth-xacml/compare/24b74b749507...37d9dd4c7128
Build details : https://travis-ci.org/fcrepo4/fcrepo-module-auth-xacml/builds/113201888
* travis-ci leaves
* bseeger joins09:19
* ajs6f joins09:28
* bseeger1 joins10:03
* bseeger leaves10:06
* peichman joins10:14
* mcritchlow joins10:37
* mcritchlow leaves10:38
* mcritchlow_ joins10:39
* bseeger1 leaves10:48
* bseeger joins10:50
* ajs6f is here
<acoburn>*is also here*11:01
* barmintor joins11:03
* barmintor sneaks onto the call11:06
* escowles joins11:08
* tjohnson joins
<escowles>Prefer: handling=lenient; received="minimal"
<ajs6f>Sounds like a small documentation issue. scossu is pretty with it and he didn't pick that up from the docs.11:09
<barmintor>I think there might be a REST semantic issue with defaulting to lenient11:10
<ajs6f>Because that's not the fullest represetnation?11:11
<ajs6f>It is magical.
<whikloj>the wonderful world of Fedisney11:12
<ajs6f>Ancient history.
A little man under the chessboard.11:13
It's not Jena.
Jena wouldn't know anything about this stuff.
<barmintor>also worth noting that "constraints" means something in the LDP spec11:15
<ajs6f> something other than what we are doing?11:16
awoods: It's lazy locking.
Like ETags.11:17
<barmintor>"no detailed knowledge of the constraints" == "no detailed knowledge of the restrictions in the constraints document"
that's how I'd read it, anyway
* dshalvi joins
<ajs6f>Unless we expose locking explicitly in the RDF, which sounds like a nightmare with horrible sauce.
Even if they don't map correctly?11:19
<barmintor>this is related to HTTP PUT not being a delta11:21
"Any LDP servers that wish to support a more sophisticated merge of data provided by the client with existing state stored on the server for a resource must use HTTP PATCH, not HTTP PUT."
* mcritchlow joins11:22
<barmintor>it's also the evil of server managed triples11:23
* mcritchlow_ leaves11:24
<whikloj>indirect container11:26
<barmintor>this is also a curious interpretation of minimal11:28
on GET -> minimal container triples; on PUT -> ignore server managed triples
<ajs6f>Once we LDP-containerize versioning and fixity, maybe server managed just turns out to mean container stuff.11:29
Having a ticket open doesn't cost us very much.11:31
As long as it's assigned to barmintor.
I agree it seems strange, like request and response are being reversed.11:32
Also assigned to barmintor.
And the revolution rages on.11:33
<acoburn>barmintor: I believe this is the relevant fcrepo code: https://git.io/v2Hum
<bseeger>not me
<acoburn>probably me11:34
<barmintor>escowles: can you try that script w/ handling=strict; received="minimal"?
<escowles>barmintor: i see the same behavior with handling=strict11:35
<barmintor>acoburn: ^^ that seems like a bug
* ajs6f is gotta go
<acoburn>barmintor: I agree
* ajs6f leaves
<escowles>it looks like handling has to be present and non-empty, but any value will do11:36
e.g., handling=x; received="minimal" works too, but handling=; received="minimal" does not11:37
i'm feeling very managed right now11:48
<barmintor>I have to run to a meeting, escowles acoburn if one of y'all files a ticket for the prefer header bug please ping me, otherwise will file this afternoon. Thanks!
<whikloj>acoburn++ # We (islandora) are interested in the indirect container updates generating events, if I can help let me know11:53
* jcoyne leaves11:55
<whikloj>+1 to delete and create11:56
<bseeger>What does that do for the version info/history of the resources? And do we care?11:57
<acoburn>bseeger: that's a separate issue from this11:59
<whikloj>bseeger: I think this is just the messaging, so not actually a delete/create. But a delete event and a create event... I think
<bseeger>ah, okay
* mcritchlow leaves12:05
<awoods>acoburn: topic: fcrepo-camel and toolbox
<acoburn>awoods: I added this PR this morning: https://github.com/mohideen/fcrepo-java-client/pull/1
awoods: once that's in place, I'd be happy with the state of the java client
awoods: alternately, I could point that PR directly at the fcrepo-exts/fcrepo-java-client
awoods: and we could move forward without mohideen's intervention12:06
awoods: thoughts?
<awoods>acoburn: Mohamed is on holiday at the moment (I believe) and this ticket has been lingering for over a month...12:07
acoburn: I suggest we move it forward
<acoburn>awoods: ok, I'll point the PR at the main code and you can squash/merge
<acoburn>awoods: then we (or I) can start cutting releases12:08
awoods: that it, I can start cutting releases
<awoods>acoburn: great. Once the code is updated, feel free to cut away.12:09
acoburn: One small note, we do not currently have a process for documenting "Release notes" for non-core releases.
<acoburn>awoods: we could establish a process12:10
<awoods>acoburn: document on with wiki? document in the github project(s)? send an email to the list?
<acoburn>awoods: I'd suggest documenting on the github project and emailing the list12:11
<awoods>acoburn: that works.
acoburn: we should also update: https://wiki.duraspace.org/display/FF/Component+Compatibility+Matrix12:12
* github-ff joins12:13
[fcrepo-java-client] acoburn opened pull request #9: add dynamic port selection (master...fcrepo-1761) https://git.io/v2H6C
* github-ff leaves
<acoburn>awoods: actually, let me squash some of those commits first ^^^12:15
* jcoyne joins12:25
<acoburn>awoods: all set: https://github.com/fcrepo4-exts/fcrepo-java-client/pull/912:27
<awoods>acoburn: please update the ticket, if you have not already: https://jira.duraspace.org/browse/FCREPO-176112:28
<acoburn>awoods: thanks, I just updated it12:30
* chadmills joins12:34
* jcoyne leaves12:37
* jcoyne joins12:38
* github-ff joins
[fcrepo-java-client] acoburn closed pull request #8: Pre-emptive Auth with IT (master...integration-test) https://git.io/vzDCX
* github-ff leaves
* bseeger leaves
* jcoyne leaves12:47
* jcoyne joins12:48
* jrgriffiniii joins12:52
* jcoyne leaves12:56
* mcritchlow joins13:04
* bseeger joins13:07
* bseeger leaves13:09
* bseeger joins
* github-ff joins13:11
[fcrepo-java-client] awoods pushed 3 new commits to master: https://git.io/v2HF8
fcrepo-java-client/master f30070a Mohamed Mohideen Abdul Rasheed: Resolves: https://jira.duraspace.org/browse/FCREPO-1761...
fcrepo-java-client/master 445dabe Aaron Coburn: add dynamic port selection...
fcrepo-java-client/master 8584528 Andrew Woods: Merge pull request #9 from acoburn/fcrepo-1761...
* github-ff leaves
* travis-ci joins13:15
fcrepo4-exts/fcrepo-java-client#21 (master - 8584528 : Andrew Woods): The build passed.
Change view : https://github.com/fcrepo4-exts/fcrepo-java-client/compare/de59b95e1de6...85845284d8bd
Build details : https://travis-ci.org/fcrepo4-exts/fcrepo-java-client/builds/113469108
* travis-ci leaves
* escowles_ joins13:18
* escowles leaves13:20
* github-ff joins13:29
[fcrepo4] acoburn opened pull request #1001: Confine all internal mode/jcr properties and type to fcrepo-kernel-modeshape (master...fcrepo-1935) https://git.io/v2Hxt
* github-ff leaves
* ajs6f joins
* bseeger leaves13:35
* bseeger joins13:38
* jcoyne joins13:47
<awoods>acoburn: I need to step out, but will give https://github.com/fcrepo4/fcrepo4/pull/1001/ a look upon returning.13:49
* mcritchlow_ joins13:59
* mcritchlow leaves14:01
* acoburn leaves14:06
* bseeger leaves14:15
* bseeger joins14:16
* bseeger leaves14:20
* jcoyne leaves14:34
* jcoyne joins14:51
* acoburn joins15:23
* ajs6f leaves15:25
<acoburn>awoods: ping15:35
<acoburn>awoods: re FCREPO-1937 (move not emitting complete events)
awoods: I'd like to widen the scope of that ticket to address DELETE and LDP membership-related operations15:36
awoods: or should those be separate tickets?
<awoods>acoburn: I think delete currently works as expected, no?
<acoburn>awoods: I don't know, I would need to checkā€¦15:37
awoods: you're right, delete works correctly15:38
awoods: but this still applies to LDP membership triples
awoods: also, events are not emitted for the root resource when a new child is added15:39
awoods: presumably, that's a bug, too
<awoods>acoburn: ldp membership operations seems like a significant expansion of scope... although important.
<acoburn>awoods: perhaps keep this ticket limited to MOVE operations and then address LDP membership separately?15:40
<awoods>acoburn: ideally, these would all be separate units of work...
acoburn: unless you feel like that will make the actual work more complicated.
<acoburn>awoods: that works for me
<awoods>acoburn: thanks15:41
acoburn: do you feel good about: https://jira.duraspace.org/browse/FCREPO-1935 ?
<acoburn>awoods: yes
<awoods>acoburn: it is a little tricky to know if there are minor, unexpected consequences
<acoburn>awoods: that's where a TCK would be really helpful15:42
<awoods>acoburn: yes15:43
<acoburn>awoods: the main change is that, rather than blacklisting JCR/MODE types to filter out, we're whitelisting those to map to fcrepo namespaces
awoods: which gives us significantly more control over what internal properties make it out of the fcrepo-modeshape layer15:45
<awoods>acoburn: What are your thoughts on the dispersed nature of determining "managed triples/properties/URIs/..."? across: RdfLexicon, FedoraTypesUtils, ContentExposingResource, ManagedRdf, ...15:47
<acoburn>awoods: I think it's a mess right now15:48
<awoods>acoburn: glad to hear it... I feel the same.
<acoburn>awoods: my biggest concern is that FedoraResource::getTriples(translator, PROPERTIES) returns a lot of server-managed triples15:49
awoods: such as fedora:created, fedora:lastModified, etc
awoods: those triples should be returned with FedoraResource::getTriples(translator, SERVER_MANAGED)15:50
awoods: another _big_ issue is the FedoraResource::getTypes vs FedoraResource::hasType
<awoods>acoburn: How would changing that impact the topic raised by Stefano today?
acoburn: i.e. if we do not give back server managed triples, can we expect PUT requests to include them?15:51
<acoburn>awoods: I think that issue is completely separate
awoods: at present, the http-api layer does extra work with the mapping b/w PROPERTIES and SERVER_MANAGED triples15:52
* dhlamb leaves15:53
<acoburn>awoods: you see here: https://git.io/v2QgW
awoods: there's a special filter for "ServerManaged" triples that come out of the getTriples(PROPERTIES) method
<awoods>acoburn: and you are trying to eliminate the need for that special filter?15:56
<acoburn>awoods: not with this PR, but it should be dealt with eventually
awoods: it would make things easier for alternate impls15:57
* mcritchlow_ leaves15:59
<acoburn>awoods: after 4.5.1 is released, can we begin work on 4.6.0 (i.e. breaking changes) or do you plan to have more releases in the 4.5.x cycle?16:05
<awoods>acoburn: A breaking changes is probably fine... but 1) we should consider how many such breaking releases we want per year and 2) we should deprecate before breaking16:07
<acoburn>awoods: the "breaking changes" I'm thinking about relate to changes in the Spring files
awoods: by injecting an additional class or two, we can entirely eliminate the fcrepo-kernel-modeshape dependency in the http layer16:08
awoods: but it's "breaking" b/c someone who has a customized spring config may need to make changes16:09
awoods: I suppose we could make the Injected value optional and provide a fcrepo-kernel-modeshape class as a default16:11
awoods: and then remove that default at some point
<awoods>acoburn: I think it is reasonable to limit our definition of "breaking changes" to HTTP API changes.16:12
<acoburn>awoods: cool, then it's not a breaking change
<awoods>acoburn: it does not sound like it... although the NodeTypes API change would be.16:13
<acoburn>awoods: true, and it would be nice not to have to keep rebasing that PR whenever we have significant changes to master16:14
* escowles_ leaves16:16
<awoods>acoburn: I am investigating a bug I hit after creating a version of a container, then selecting that version in the HTML UI...16:33
<acoburn>awoods: is it related to this PR or is it in master?
<awoods>acoburn: not sure yet...
acoburn: not here: http://demo.fcrepo.org:8080/fcrepo/rest16:34
acoburn: which is master
<acoburn>awoods: I don't see it locally (with PR #1001 applied)
* dwilcox joins16:38
<awoods>acoburn: try creating a container, creating a contained binary, creating a version of the binary, then creating a version of the container.
acoburn: then accessing the container version16:39
<acoburn>awoods: what is the bug?16:41
<awoods>acoburn: 404 when accessing the container version
acoburn: I only see it after creating a version of the contained binary
* peichman leaves16:42
<acoburn>awoods: Oh, I versioned the container, not the binary. I'll try that
<awoods>acoburn: after you version the binary, then go back and version the container
<acoburn>awoods: the other way around certainly seems to work16:43
awoods: ok, I get that error, too16:44
<awoods>acoburn: probably unrelated to 1001
<acoburn>awoods: I'll try building master and seeing if it's there, too16:45
awoods: I get that same error with a fresh build on the master branch16:50
<awoods>acoburn: me too
* jgpawletko leaves
<awoods>acoburn: it does not need to be a contained binary. Contained containers also cause the error16:52
<acoburn>awoods: yes, I see that, too16:53
awoods: I also noticed that if you version a parent container with child PairTree nodes, those PairTree nodes become Containers in the versioned representation16:54
awoods: which doesn't seem right16:55
awoods: that's in the build from master
<awoods>acoburn: bugs
<acoburn>awoods: oh wait, they don't become Containers, they are just fedora:Version types (they are ldp:Containers)16:56
awoods: not fedora:Container
awoods: but also not fedora:PairTree
<awoods>acoburn: there is probably a blocker bug or two in here16:57
<acoburn>awoods: yes, probably16:58
awoods: though on a positive note, if we don't have a release candidate for another week or two, I may have time to sneak in FCREPO-1937 (MOVE events)16:59
<awoods>acoburn: true
<whikloj>awoods: sorry to intrude, but do you have a second?17:02
<awoods>whikloj: sure
<whikloj>awoods: I think I am doing something wrong, as I am not seeing the same 404 you are for FCREPO-1933.17:04
awoods: I think I built everything new with fresh pulls on master, but I was able to generate a container inside a transaction17:05
awoods: is there anyway to tell if the authentication prompt I am getting is for webac (vs rbacl, etc)17:06
<awoods>whikloj: Not that I know of...
<whikloj>awoods: and lastly I did this with a fedoraAdmin user added to my tomcat-users.xml file with fedoraAdmin role. You didn't specify the user you were using, but I assumed an admin?17:07
<awoods>whikloj: because of the debugging I am currently in, my local builds are not in a state to retest 1933
whikloj: ?? are you not using webapp-plus?
<whikloj>awoods: yes, I build it and deployed the WAR to an existing tomcat container. Is that not what you are doing?17:08
<awoods>whikloj: I probably used "mvn jetty:run" on webapp-plus17:10
<whikloj>awoods: I will try that
* acoburn leaves17:13
* jrgriffiniii leaves17:14
* dwilcox_ joins
* dwilcox leaves17:16
* github-ff joins17:24
[fcrepo4] awoods pushed 1 new commit to master: https://git.io/v2Q58
fcrepo4/master 02f98e1 Aaron Coburn: Confine internal modeshape/jcr types and properties to fcrepo-kernel-modeshape module....
* github-ff leaves
* github-ff joins17:25
[fcrepo4] awoods closed pull request #1001: Confine all internal mode/jcr properties and type to fcrepo-kernel-modeshape (master...fcrepo-1935) https://git.io/v2Hxt
* github-ff leaves
* mcritchlow joins17:34
* jgpawletko joins17:41
* travis-ci joins17:44
fcrepo4/fcrepo4#4346 (master - 02f98e1 : Aaron Coburn): The build passed.
Change view : https://github.com/fcrepo4/fcrepo4/compare/0ff7526579f5...02f98e1ac64c
Build details : https://travis-ci.org/fcrepo4/fcrepo4/builds/113524318
* travis-ci leaves
* rbenji leaves17:53
* whikloj leaves18:00
* dwilcox_ leaves18:04
* mcritchlow_ joins18:08
* mcritchlow leaves18:09
* mcritchlow_ leaves18:10
* mcritchlow joins18:17
* jcoyne leaves18:20
* jcoyne joins
* mcritchlow leaves18:41
* jgpawletko leaves18:53
* jcoyne leaves18:54
* mcritchlow joins19:37
* jgpawletko joins19:59
* mcritchlow leaves20:20
* tjohnson leaves21:04
* jcoyne joins22:20
* mcritchlow joins23:17
* dwilcox joins23:45
* dwilcox_ joins23:48
* dwilcox leaves23:50
* mcritchlow leaves00:08
* dwilcox_ leaves00:49

Generated by Sualtam