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

Using timezone: Eastern Standard Time
* bryjbrown leaves01:24
* westgard1 leaves01:38
* westgard1 joins02:01
* westgard1 leaves02:14
* westgard1 leaves04:04
* jonathangee leaves05:39
* westgard1 joins05:48
* westgard1 leaves05:53
* jonathangee joins05:55
* westgard1 joins07:37
* dwilcox joins07:40
* westgard1 leaves07:42
* apb18 joins08:27
* dwilcox leaves08:33
* dwilcox joins08:39
* benpennell joins09:04
[API Alignment Standup]09:06
I am going to be unavailable until around 1:30pm
Finished yesterday:
* Further reading on Memento specification, Fcrepo specification, existing fcrepo versioning api
* Taking notes to articulate versioning tickets
* Discussed versioning and ACL components of specification
Working on today:
* Continue trying to pull together versioning tickets
* Continue discussing versioning and ACL design
* none
* harringj joins09:07
<apb18>Thanks benpennell!09:08
* dwilcox leaves
<harringj>API Alignment Standup09:13
Finished yesterday:
(In review) FCREPO-2593: LDP-NR creation failures must use the correct response code
Working on today: Addressing PR feedback for FCREPO-2593
      Start work on FCREPO-2600
Blockers: none
* yamil joins09:15
<apb18>Thanks harringj!
* westgard1 joins09:26
* bseeger joins09:27
[API Alignment Standup]09:29
Finished yesterday:
Parsed memento spec more, started thinking about a few design options for version,
{and/or brief textual description}
Working on today:
{ticket titles and associated JIRA links}
{and/or brief textual description}
(ignore that — not done yet… whoops!)
* dwilcox joins09:31
* westgard1 leaves
<bseeger>[API Alignment Standup]
Finished yesterday:
  Parsed memento and api spec more, started thinking about a few design options for versioning,
Working on today:
  Read SOLID WebAC spec, continue looking at current fcrepo implementation of versioning/WebAC and crafting a plan for how to bring the current implementation into conformance with the spec.
Blockers: none09:32
<escowles_>[API Alignment Standup]
Finished yesterday:
- FCREPO-2584 using Link header for interaction model instead of
mime-type sniffing
- FCREPO-2592 containers advertise constraints in a constraints
Working on today:
- working through CRUD tickets
- none
<apb18>escowles, bseeger: Thanks!09:43
* dwilcox leaves09:49
* dwilcox joins09:55
* github-ff joins10:12
[fcrepo-specification] zimeon opened pull request #216: Fix JSON-LD context typo (master...context-typo) https://git.io/v5y5a
* github-ff leaves
* bryjbrown joins10:17
<harringj>apb18: i replied to your comments on my PR. just put one follow-up question there10:32
* lsitu joins10:34
* bryjbrown leaves10:35
<apb18>harringj: Yup, looking at it right now! By the way, there are eclipse settings that allow it to ignore certain kinds of warnings. Mine is set to _not_ to suppress the resource leak warnings, which is why they were so apparent.
<harringj>apb18: ok, thanks for the tip!10:37
<lsitu>API Alignment Standup]10:39
Finished yesterday:
Coding for Support Want-Digest header on HEAD and GET of LDP-NRs: https://jira.duraspace.org/browse/FCREPO-2601
Working on today:
Wrapup ticket Support Want-Digest header on HEAD and GET of LDP-NRs: https://jira.duraspace.org/browse/FCREPO-2601
NonRDFSource link header must be supported regardless of ContentType: https://jira.duraspace.org/browse/FCREPO-2590
* whikloj joins10:40
<apb18>Thanks, lsitu!
* github-ff joins10:47
[fcrepo4] birkland pushed 1 new commit to 4.7-maintenance: https://git.io/v5yxc
fcrepo4/4.7-maintenance 5e281d1 Peter Eichman: Upgrade to Modeshape 5.4.0.Final (#1226)...
* github-ff leaves
* westgard joins
<lsitu>escowles: I am looking for tickets. Do you mind if I work on the ticket https://jira.duraspace.org/browse/FCREPO-2590 for NonRdfResource?10:48
Please feel free to asign any tickets to me if you have anything else in mind thta you would like me to work on. Thanks.
* github-ff joins10:49
[fcrepo4] birkland closed pull request #1227: Upgrade to Modeshape 5.4.0.Final (master...FCREPO-2581) https://git.io/v5Kcq
* github-ff leaves
<escowles>lsitu: i think that FCREPO-2590 is a copy of FCREPO-2854 (which i'm working on already)10:52
but i think these are all good to work on: https://jira.duraspace.org/browse/FCREPO-2596 https://jira.duraspace.org/browse/FCREPO-2589 https://jira.duraspace.org/browse/FCREPO-2588 https://jira.duraspace.org/browse/FCREPO-2587 https://jira.duraspace.org/browse/FCREPO-2586 https://jira.duraspace.org/browse/FCREPO-258510:56
<lsitu>escowles: Thanks.
<westgard>sorry for the tardy standup report10:57
[API Alignment Standup]
Finished yesterday:
- created page for use-cases and examples of vers/auth interaction
- created requirements for a simple use-case
Working on today:
- trying to create a concrete example of the requests/responses to illustrate the use-case
- none, but if anyone needs a task and has a use-case, we could use more
- https://wiki.duraspace.org/pages/viewpage.action?pageId=90964645
* harringj leaves10:59
* travis-ci joins11:06
fcrepo4/fcrepo4#5118 (4.7-maintenance - 5e281d1 : Peter Eichman): The build passed.
Change view : https://github.com/fcrepo4/fcrepo4/compare/971b5c7d6675...5e281d1bb8b0
Build details : https://travis-ci.org/fcrepo4/fcrepo4/builds/275072229
* travis-ci leaves
* github-ff joins11:07
[fcrepo4] lsitu opened pull request #1231: Support Want-Digest header with fixity check for NonRDFSource. (master...feature/want_digest) https://git.io/v5yjn
* github-ff leaves
<apb18>thanks westgard !11:10
* benpennell leaves
* harringj joins11:14
* westgard1 joins11:15
* peichman joins11:16
* westgard1 leaves11:20
<dbernstein>[API Alignment Standup]11:47
Finished yesterday:
Helped situate Joe Harrington
Working on today:
Wrapping up https://jira.duraspace.org/browse/FCREPO-2602
(Use Activity Streams JSON for message bodies)
https://jira.duraspace.org/browse/FCREPO-2603 (Use proper actor values for emitted messages
https://jira.duraspace.org/browse/FCREPO-2594: PUT must fail with 409 if trying to change interaction model to non-subtype
* dwilcox leaves
* harringj leaves11:48
* lsitu leaves11:53
* lsitu joins11:54
* dwilcox joins11:56
* bseeger leaves12:07
* harringj joins12:25
* harringj leaves12:27
* bseeger joins12:33
* westgard1 joins13:04
* westgard1 leaves13:08
* harringj joins13:20
* peichman leaves13:39
* benpennell joins13:48
* peichman joins13:50
* github-ff joins14:15
[fcrepo4] birkland pushed 1 new commit to master: https://git.io/v5S41
fcrepo4/master 3ae0d6f harringj: Ensures correct response codes for creating LDP-NR (#1228)...
* github-ff leaves
* travis-ci joins14:29
fcrepo4/fcrepo4#5123 (master - 3ae0d6f : harringj): The build passed.
Change view : https://github.com/fcrepo4/fcrepo4/compare/e93786bcef01...3ae0d6f71883
Build details : https://travis-ci.org/fcrepo4/fcrepo4/builds/275154060
* travis-ci leaves
<apb18>lsitu: it looks like your PR now has conflicts, based on merging harringj's PR. In particular, you both added a new exception class to represent unsupported digest algorithms14:31
<lsitu>apb18: I’ll rebase it.14:32
<apb18>Great. you will probably need to use the UnsupportedAlgorithmException class that was introduced in harringj's PR.
thank you very much lsitu. For your reference: https://github.com/fcrepo4/fcrepo4/pull/122814:33
* westgard1 joins14:53
<benpennell>bseeger: westgard: hey i'm back now, just checking in and trying to catch up on how things are going with the versioning stuff14:55
<bseeger>benpennell, westgard: I've read through the SOLID webac spec and am currently looking at how versions work in the current fedora impl.14:56
looking more at how they work, I should say. :)14:57
just realizing that 'reverting to a different version' is a modeshape implementation feature and not required by the spec.
* westgard1 leaves14:58
<bseeger>fedora modeshape impl feature that is
<benpennell>yeah, I have a note about checking to see if that feature is being retired
I guess that sort of thing gets posed as an issue on the specification?14:59
<westgard>bseeger benpennell: I am still looking at the documents and working on examples to illustrate how the use-case I created might go.
<bseeger>I don't know - I think the spec is currently silent on this feature with good reason15:00
I think it's more of whether or not fedora-tech thinks that feature should stay in. I don't think it should be in the spec.
<benpennell>bseeger: the spec does say "An implementation must not support PATCH for https://fcrepo.github.io/fcrepo-specification/#dfn-ldprms.", which would appear to directly address the reversion api. i'm not clear if that was the intention or not tohugh15:02
<bseeger>I think that covers the bases of saying a LDPRm is immutable and might not be a statement on reverting to an older version.15:04
* westgard1 joins15:07
<benpennell>right, I agree, i think that is what the intention was, it just happens to overlap with how we are currently mapping the old API to new concepts15:09
* peichman leaves
* westgard leaves15:10
<benpennell>it also complicates forward porting that feature
* westgard1 leaves15:11
<bseeger>good point - since PATCH isn't allowed… we would probably have to change how reverting versions is triggered15:17
if the group still wants to support this feature15:18
<escowles>i think disallowing PATCH is to prevent modifying old versions
<bseeger>escowles — are LDPR's and LDPRv's separate entities in the system? I wouldn't think so, but… I keep wondering if that's the case?15:22
<escowles>no, in the modeshape impl they are the same thing
<bseeger>would that be the case in any system?15:24
<escowles>bseeger: you could have a system where some resources were versionable but others weren't15:25
<benpennell>escowles: one thing related to whether LDPR's and LDPRv's are the same or not comes when trying to classify what to consider an object like </a/fcr:versions/v1/b>, so a child of a versioned tree
<escowles>hmm... maybe those are LDPRs, but not LDPRvs? because it's a resource, but you can't create a version of it?15:26
's not an LDPRm either
I guess that is okay?15:27
<escowles>right, </a/fcr:versions/v1> is the LDPRm, right?
<benpennell>i believe so
we haven't been quite sure how that case was expected to be handled since its not mentioned in the specification15:28
<escowles>maybe you could use COPY to copy the version back to the original resource?15:29
<benpennell>that would work. I wonder if that should be mentioned in the specification? all of the memento creation stuff is fcrepo specific, so I'm not sure there is a reason to leave out that particular feature15:31
<escowles>this seems like a good spec issue to create, because we should have some way to restore versions15:33
<bseeger>I actually like that the spec is silent on it - or at least that it wouldn't require a restore15:34
<benpennell>I can agree with it not requiring it, but it seems reasonable to have it as a MAY since its already present in the reference impl
<bseeger>but I'm not sure I followed all the above15:35
<escowles>i don't have a strong opinion about including it or not — but i think the spec should allow some way of restoring versions
i think changing the LDPRm PATCH to "An implementation must not support PATCH for modifying LDPRms"
so we could still use PATCH to restore them, might be a good idea15:36
<bseeger>yeah, that language change would be useful15:37
<benpennell>so suggest that the specification be changed to PATCH ldprm would do a restore, and mention that it also can't be used to change the ldrpm?
<escowles>i created an issue for this: https://github.com/fcrepo/fcrepo-specification/issues/217
<bseeger>Hmm.. I'd keep out the restore part, just that a PATCH cannot be used on a LDPRm to modify it…?
<apb18>Hm, so why wouldn't a restore be a PATCH to the LDPRv? It's like in git where you "revert" by adding a commit that restores the state to what you want15:40
<benpennell>i guess that's what it would be if you did the restore yourself rather than having an API endpoint dedicated to it
<apb18>Yeah. I think the motivation for an API to do it comes from the snapshot/tree method that fcrepo4 uses15:41
<benpennell>but git does have a command specifically dedicated to do thing this operation
<escowles>yeah, maybe we could PATCH the LDPRv with a header that points to the version?
<bseeger>that seems more intuitive15:42
<benpennell>sorry, "git does have a command specifically dedicated to doing revert operations"
<bseeger>btw, in that scenario abp18 described yesterday where you have /a that contains b and then you version 'a', which therefore versions b as well… well, if you change b in the mean time and then revert that 'a' snapshot, you overwrite b as well.15:44
which just seems like a bug
(or is it…)15:45
<apb18>bseeger: or a feature :) I don't know. If you're doing trees, do you want to revert the tree, or just one part of it?
<benpennell>i've never actually tried that, seems kind of destructive15:46
I wonder what happens to the other versions of b since a was snapshotted15:47
<bseeger>because you can have two separate snapshot paths going on — b's own and then via 'a'?15:48
<apb18>lsitu: It looks like you rebased pr/1231. Is it safe to review now?
<lsitu>apb18: Yes. I’ve done with rebasing and it’s ready for review now. Thanks.15:50
<apb18>lsitu: Wonderful, I'll take a look. Thanks!
<bseeger>benpennell - this is interesting. If you version 'a' and then version 'b' the ldp contains triple for a_v1 now contains /a/b/fcr:versions15:51
for b15:52
<apb18>uh oh?
<benpennell>bseeger: interesting. I just tried my scenario out and it looks like even though be got wiped out, b still had the version from before being restored, which seems good?
and i see that too, mine has: <c1/fcr:versions/v1> ldp:contains <c1/c2/fcr:versions>15:54
<bseeger>looks like a restore of 'a' still wipes out 'b', but you can revert to any 'b' versions you had saved.15:55
You just lose the lastest stuff you had on there.
<benpennell>but it autosnapshots a before you revert it, so you would probably still have the changes to b in there15:56
ignoring the fact that the snapshotted version of a points to a/b/fcr:versions
yeah, looks like the autosnapshot has the properties if i manually input its uri15:57
properties I added to b prior to wiping it out by reverting a that is15:58
pretty sure you spotted a new bug species there with the ldp:contains though
<bseeger>Oh, interesting… it makes a difference if you version 'b' before you version 'a' - not sure how that plays out though. If I version 'a' first, then the link is always 'a's snapshot of 'b'. But if I version 'b' first, then I get the fcr:versions link.16:00
<benpennell>hmm, i think i might have to try that to follow16:03
<apb18>escowles: Out of curiosity, should the spec mention (non-normatively) that a client SHOULD use Cache-Control: no-cache when using Want-Digest for the purpose of persistence fixity, to make sure that the request doesn't get answered by any caching proxies that are between the client and Fedora?
<escowles>apb18: that would probably be a good idea
<apb18>OK. shall I create an issue then? was just inspired while reading lsitu's PR16:06
<escowles>apb18: yes, please create a spec issues for that16:07
<benpennell>bseeger: okay, now i'm really confused. I created a, created b, versioned b as vb, versioned a as va. Looking at version va of a, I see: </a/fcr:versions/va> ldp:contains </a/b/fcr:versions/vb>
wonder if its because i didn't change anything before creating versions?16:09
<bseeger>benpennell: were you seeing /a/b/fcr:versions/ before? I think I was at one point, but can't remember how I got there.
* mcritchlow joins16:14
* escowles leaves16:15
* escowles joins16:16
<harringj>i'm working on FCREPO-2600 https://jira.duraspace.org/browse/FCREPO-2600, but i'm not seeing any refs to depth in the fedora code base 16:23
i see that delete() is implemented in FedoraResourceImpl, FedoraBinaryImpl, and TombstoneImpl, but don't see where depth is being accounted for.
anyone have thoughts on this? is the depth header stuff completely new functionality?
<escowles>harringj: yes, Depth is completely new16:24
i think the modeshape impl supports 0 or infinity for binaries, and infinity for containers
everything else should throw an error
<harringj>escowles: thanks for clarifying!16:25
* westgard1 joins16:41
* westgard1 leaves16:46
* harringj leaves16:47
* bseeger leaves17:13
* bryjbrown joins
<apb18>I'm heading to pick up the kids now, have a good day
* apb18 leaves17:18
* benpennell leaves17:23
* bryjbrown leaves17:44
* apb18 joins17:46
* whikloj leaves17:57
* apb18 leaves18:07
* dwilcox leaves18:12
* westgard1 joins18:30
* westgard1 leaves18:34
* yamil leaves18:42
* github-ff joins18:57
[fcrepo4] dbernstein opened pull request #1232: PR is a two in one: fcrepo-2602 and fcrepo-2603 (master...fcrepo-2602) https://git.io/v5ShC
* github-ff leaves
* apb18 joins19:38
* apb18 leaves19:43
* mcritchlow leaves19:51
* dwilcox joins20:07
* dbernstein leaves
* westgard1 joins20:19
* westgard1 leaves20:24
* dwilcox leaves20:26
* escowles_ joins21:32
* westgard1 joins21:33
* escowles leaves21:35
* bryjbrown joins22:29
* benpennell joins22:30
* lsitu leaves22:33
* benpennell leaves
* benpennell joins
* westgard1 leaves22:37
* bryjbrown leaves22:45
* dbernstein joins22:52
* benpennell leaves22:57
* benpennell joins
* github-ff joins23:00
[fcrepo4] birkland pushed 1 new commit to master: https://git.io/v593c
fcrepo4/master 6652793 lsitu: Support Want-Digest header with fixity check for NonRDFSource. (#1231)...
* github-ff leaves
* bryjbrown joins23:13
* travis-ci joins23:18
fcrepo4/fcrepo4#5127 (master - 6652793 : lsitu): The build passed.
Change view : https://github.com/fcrepo4/fcrepo4/compare/3ae0d6f71883...665279352ef7
Build details : https://travis-ci.org/fcrepo4/fcrepo4/builds/275299833
* travis-ci leaves
* f4jenkins leaves23:37
* f4jenkins joins23:38
* benpennell leaves23:42
* bryjbrown leaves23:58
* westgard1 joins00:21
* westgard1 leaves00:26

Generated by Sualtam