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

Using timezone: Eastern Standard Time
* cbeer_ leaves00:30
* cbeer joins00:32
* dwilcox joins06:55
* awoods joins06:59
* github-ff joins08:34
[fcrepo4] birkland closed pull request #1235: Include Content-Location header in external content GET and HEAD responses. (master...feature/content_location) https://git.io/v5HpS
* github-ff leaves
* apb18 joins08:37
* harringj joins08:39
* dwilcox leaves08:49
* travis-ci joins08:50
fcrepo4/fcrepo4#5144 (master - 1b2d4e8 : lsitu): The build passed.
Change view : https://github.com/fcrepo4/fcrepo4/compare/fc57d9797187...1b2d4e821fc3
Build details : https://travis-ci.org/fcrepo4/fcrepo4/builds/275869110
* travis-ci leaves
* bseeger joins09:09
escowles - are you free at 11 am?09:20
<escowles>bseeger: yes, i am09:21
<bseeger>apb18, benpennell, escowles: how about we meet to talk about azn/versioning then? (anyone is welcome)09:24
<benpennell>bseeger: works for me09:25
<apb18>I'll have to join :15 late, but don't wait up
By the way, thinking about FCREPO-2603:https://jira.duraspace.org/browse/FCREPO-260309:26
.. made me wonder how *will* we get the URI that identifies the current user (or group). Is that a question for the auth/versioning subgroup bseeger or benpennell ?09:27
* yamil joins09:28
<benpennell>it does seem webac related, but i wouldn't think it would be related to persistence so much as request headers09:30
<apb18>benpennell: Which request headers? It may be a stupid question.09:31
<bseeger>are we limiting azn to the local server - else that PR does limit us to that.09:32
<escowles>we've talked about that a bit before — the simplistic approach would be to just append the usernames to a base URI to make them URIs — but in theory you could have code that did something more sophisticated
<bseeger>so no remote users / groups then? (just confirming - I can see good reason why to limit it to the local server)09:33
<apb18>bseeger: Actually, the PR was meant for https://jira.duraspace.org/browse/FCREPO-2602
.. and it had "For now, use a local hash URI #agent for the actor, and populate its name with the string name of the user principal."09:34
The intent of FCREPO-2603 was to, once there is a known way to get the real user URI, put that in messages as the actor
<bseeger>actually, I misinterpreted it — the baseURL could point to another server altogether. It just implies one source of verification for our users. Which is probably totally fine.
* github-ff joins09:35
[fcrepo4] escowles created embed-contained-descriptions (+1 new commit): https://git.io/v57cp
fcrepo4/embed-contained-descriptions b03d446 Esmé Cowles: Support oa:PreferContainedDescriptions prefer header
* github-ff leaves
<apb18>but in general, I was wondering if the versioning/auth subgroup would answer that question, "where do we get the user's identity as a URI?".09:36
* github-ff joins09:37
[fcrepo4] harringj opened pull request #1236: Adds support for depth header to DELETE action (master...fcrepo-2600) https://git.io/v57Ct
* github-ff leaves
<apb18>If not, I'll add a ticket. It may be trivially satisfied by what's in FCREPO-2602, if that's what we decide to do for the long haul
<bseeger>I'd suggest adding a ticket and if we can get there great.
<apb18>(FCREPO-2602 either appends the string userid to a local hash uri #fedoraAdmin, or to a globally configured uri)09:38
<bseeger>the simplified approach seems good for now - what escowles mentioned of taking the usernames onto a baseuri
<apb18>I'll create a ticket. In the code base, there needs to be a way for webac and for messaging to get that URI (from some internal service/component that has the role of producing it).09:42
<harringj>API Alignment Standup09:43
Finished yesterday:
Nothing wrapped up yesterday, but worked on FCREPO-2600, which turned out to have some unexpected wrinkles
Working on today:
 Just submitted PR for FCREPO-2600; has some conflicts with the main branch that will need to be sorted out; will grab another ticket shortBlockers:
<apb18>If we're just appending a hash to a URI, that's fine.. but it ought to happen in a component for whom that is a designated role, rather than constructing them locally when needed
* peichman joins09:44
<bseeger>total agreement here - also makes it easier to make it more sophisticated down the road - if it's all encapsulated in one place versus spread out in the code.
I think any code that needs that info should query some service/module for it.
then that module could operate off a JAVA_OPT var for now.
(I have no clue how the webac code is organized right now, but it might provide for this sort of access)09:45
<apb18>bseeger: the webac code is outside of the main code base. So if it does have one, the solution to that ticket would be to move it in to core.09:46
<escowles>[API Alignment Standup]
Finished yesterday:
- FCREPO-2584 using Link header for interaction model, but fallback on mime type
Working on today:
- FCREPO-2595 use oa:PreferContainedResources to embed children
- any other CRUD tickets
- lots of meetings again
<bseeger>abp18 - is webAC required by the spec? It doesn't read like it is, right?09:47
"To configure access control restrictions, implementations must follow the recommendations of Web Access Control [https://fcrepo.github.io/fcrepo-specification/#bib-SOLIDWEBAC] with the following additional requirements:"09:49
<escowles>yep, definitely required09:50
<bseeger>That says to me, IF you use azn, here's what you have to do.
<escowles>oh, i see the ambiguity there — if you don't do auth at all, then you don't need to do webac
<bseeger>yeah - is that the intention, or must an impl have azn at all?09:51
For azn - wouldn't an approach be to pass in the full ID of the user and not just the username anymore?09:52
* travis-ci joins
fcrepo4/fcrepo4#5145 (embed-contained-descriptions - b03d446 : Esmé Cowles): The build passed.
Change view : https://github.com/fcrepo4/fcrepo4/commit/b03d44682ed1
Build details : https://travis-ci.org/fcrepo4/fcrepo4/builds/275892409
* travis-ci leaves
<escowles>i'm not sure — i wonder if apb18 was around for some of that discussion? i can ask awoods and the other editors about the intention there09:53
* awoods reading above
escowles/bseeger: Is the question whether WebAC is required?09:55
<bseeger>awoods: wether any azn is required
awoods: I read it the spec as saying, "IF you do azn, it should be via WebAC"
<escowles>awoods: yes — the spec says you have to use webac for auth, but it doesn't actually say you have to do auth
<apb18>escowles, I don't believe I was around. It's unclear to me if the expectation (of SOLID) is that usernames _are_ URIs, or there is some other infrasturcture that provides it, i.e. as part of an authn negotiation09:56
<awoods>escowles/bseeger: As a core feature, yes, WebAC (and AuthZ) is required.09:57
apb18: there are two questions floating in this thread
<apb18>awoods: yes09:58
<awoods>apb18: From the SOLID and Fedora Spec perspective, all agents are identified with URIs.
<apb18>awoods: Yes, the first question (I'm creating an issue) is how (in the code base) do we make that URI available to components that need it09:59
<bseeger>awoods, apb18 - what I wonder is if the full URI for that person/group is part of the original request.
Right now we use usernames, but that should probably change to to be the full uri10:00
<apb18>bseeger: like, instead of logging in as fedoraAdmin, you're http://localhost:8080/fcrepo/rest/users#fedoraAdmin (or something like that)?10:01
<awoods>bseeger/apb18: We currently have support for requests that contain string usernames as well as URIs.
<bseeger>apb18 - right, that's what I'm wondering
<apb18>OK. So if it's a string, then the strategy of appending it as a hash to some (possibly globally configured) URI is fine.10:02
(albeit, we still need a core component that does that and provides it)10:03
for a URI, we just pass it through
<awoods>apb18: Agreed, recognizing that some clients will still be using String identifiers, supporting the "-Dfcrepo.auth.webac.userAgent.baseUri" allows them to work in the WebAC space.
<apb18>for more complex stuff, like shibboleth, that infra can either provide a string (which would be appended to that URI just like anything else), or provide a URI.10:04
<bseeger>apb18 - going back a few questions — since azn is required as a core component, it would make sense to pull webac into the core code base.10:05
<apb18>bseeger: I agree
There's also nastiness where webac depends on rbacl at the moment, but this'll give an opportunity to just take the stuff we need and dump the rest.10:06
<escowles>+1 to refactoring and merging back into the core codebase10:07
<apb18>OK. So I'll create those tickets, and the versioning/auth subgroup won't specifically worry about it. Take the existence and accessibility of user URIs as a given.10:09
<bseeger>apb18++ #thanks!
<apb18>y'all have much harder problems to worry about :)10:11
* lsitu joins
<benpennell>i periodically see if in the documentation, but what was ixn mean?10:13
<apb18>escowles: Good deal on closing FCREPO-2599. The servlet container (and proxies) will do whatever they want, whether we like it or not!
<escowles>benpennell: interaction
<benpennell>thanks escowles
* dwilcox joins10:14
<lsitu>[API Alignment Standup]10:15
Finished yesterday:
Ensure correct behavior of returning Preference-Applied header: https://jira.duraspace.org/browse/FCREPO-2596
External content GET and HEAD responses should include Content-Location header: https://github.com/fcrepo4/fcrepo4/pull/1235
Working on today:
Add support for Want-Digest header to external content: https://jira.duraspace.org/browse/FCREPO-2587
<benpennell>[API Alignment Standup]10:20
Finished yesterday:
* Initial draft of versioning tickets https://wiki.duraspace.org/pages/viewpage.action?pageId=90964556 Draft Tickets section
Working on today:
* Updates to delta document
* Continue discussing and creating examples for versioning and ACL design
* none
* escowles leaves10:21
* escowles joins
<apb18>new ticket for user ID URIs: https://jira.duraspace.org/browse/FCREPO-260810:29
* whikloj joins10:33
<apb18>new ticket for moving webac into core: https://jira.duraspace.org/browse/FCREPO-260910:35
<bseeger>dial in via this page to talk about auth/versioning… it'll be fun, I promise! https://wiki.duraspace.org/display/FF/2017-09-11+API+Alignment11:01
https://fcrepo.github.io/fcrepo-specification/#general-3 <— LDPCV timemap
* mcritchlow joins11:32
* mcritchlow leaves11:55
* mcritchlow joins11:56
<escowles>sorry, i've got to drop — gotta eat some lunch and get ready for my 1pm meeting12:04
<benpennell>thanks for participating escowles!
<bseeger>yes, thanks for joining us escowles and apb1812:08
* dbernstein joins12:24
* bseeger leaves12:39
<apb18>dbernstein: FYI there was a bit of chatter regarding URIs for users this morning, resulting in a new ticket: https://jira.duraspace.org/browse/FCREPO-260812:46
It's possible harringj might be interested in it, or working/coordinating with you; given the ticket on agents in messages12:47
<harringj>dbernstein: yes, i'm just trying to get a handle on what it would involve. happy to work with you on it, or you can grab it if you're interesteed12:48
<dbernstein>harringj and apb18: let me take a look.12:50
let me review the chatter - one sec…12:53
* peichman leaves
* peichman joins12:55
<dbernstein>harringj and apb18: so I think I understand most of the issue. Basically, the change for https://jira.duraspace.org/browse/FCREPO-2608 is to check if the username is a URI and if so pass that value as the actor rather than creating a hashuri or appending to the global base uri. Do I have that straight?12:59
<apb18>dbernstein: Most importantly, it's adding implementation that does this, and makes it available via as a kernel API call.13:01
dbernstein: There may already be such logic in the webac code, I don't know.13:02
The FedoraSession in fcrepo-kernel-api gives user id as a string. SO the fox in 2608 will involve changing the signature to a URI, and dropping the logic into the impl.13:03
* github-ff joins13:04
[fcrepo4] birkland pushed 1 new commit to master: https://git.io/v57Dd
fcrepo4/master d94fd5a lsitu: Ensure correct behavior of returning Preference-Applied header for Get request. (#1233)...
* github-ff leaves
<harringj>apb18: fox?13:06
* bseeger joins13:08
<apb18>harringj: typing fail
<apb18>harringj: Can you resolve conflicts and rebase to fox https://github.com/fcrepo4/fcrepo4/pull/123613:09
<bseeger>what is this fox?
<harringj>apb18: yep, sure thing!13:10
<apb18>bseeger: It is a reflection of my typing skills, and the proximity of o to i
just remove the 'o' key, I don't think it's really needed.
just remve the '' key, I dn't think it's really needed.
<apb18>Te vwls r jst ns nywy13:12
<dbernstein>harringj: I’ll jump on 2608 unless you are burning to work on it.
<bseeger>dwn wth vwls!13:13
<harringj>dbernstein: go for it, and let me know if you'd like a hand
<apb18>harringj, dbernstein there's also a (somewhat) related issue of moving webac into the core code base13:14
the URI part might have some sort of implementation already in webac that needs to be moved to kernel-impl13:16
but otherwise, I *think* much of the webac could go in without too much trouble.
<harringj>apb18: just finished rebasing. travis is chugging along, and that PR should be ready for review13:31
* dwilcox leaves13:32
<dbernstein>[API Alignment Standup]13:33
Finished yesterday:
Working on today:
reworking https://jira.duraspace.org/browse/FCREPO-2603
(Use proper actor values for emitted messages
reworking https://jira.duraspace.org/browse/FCREPO-2602
(Use Activity Streams JSON for message bodies)
Advertise each supported external content type in Accept-Post response header
Unsupported external-body access-types must result in 415 Unsupported Media Type
PUT must fail with 409 if trying to change interaction model to non-subtype
<bseeger>[API Alignment Standup]13:34
Finished yesterday:
Working on today*
{ticket titles and associated JIRA links}
{and/or brief textual description}
{brief textual description}
ugh, ignore that…
* dwilcox joins13:36
<bseeger>[API Alignment Standup]13:37
Finished yesterday:
Initial draft of versioning tickets https://wiki.duraspace.org/pages/viewpage.action?pageId=90964556 Draft Tickets section
Working on today:
Algorithm for finding ACLs for mementos
Update to deltad doc for versioning and webac
Design of how versions work
<apb18>harringj: Sorry, it looks like something happened during the rebase - some commits look duplicated, and there's a Preference-Applied commit in it.13:54
so.. would it be possible to13:55
- create a new branch off of the current master
- git cherry-pick 406cd50, d6882f6, and cd261b5 into that branch13:56
* lsitu leaves13:57
<harringj>apb18: whoops, i'm not sure what happened there
<apb18>-- if it looks good, just create a new PR off that branch.
(or feel free to clobber the current one with that clean branch, whatever works)
* lsitu joins
<apb18>harringj Yeah, I don't know. The Preference-Applied stuff appears in the diff, which isn't what was intended13:58
* github-ff joins14:17
[fcrepo4] harringj opened pull request #1237: Fcrepo 2600 new (master...fcrepo-2600-new) https://git.io/v57Fx
* github-ff leaves
<harringj>apb18: new PR created. branch is creatively titled fcrepo-2600-new :)14:18
although, there is still some weirdness with the commits, i'm now noticing. i may need some assistance escaping from git hell14:20
* github-ff joins14:22
[fcrepo4] birkland closed pull request #1236: Adds support for depth header to DELETE action (master...fcrepo-2600) https://git.io/v57Ct
* github-ff leaves
<apb18>harringj: no problem. The new PR is fine, I'll just make a squash commit when it's time to merge14:27
<harringj>apb18: thanks, and sorry for the trouble!14:28
<apb18>No trouble!14:29
* dwilcox leaves14:32
* harringj1 joins14:46
* harringj2 joins14:48
* harringj1 leaves
* harringj leaves14:49
* peichman leaves14:52
* peichman joins14:56
* peichman leaves
* peichman joins14:57
* peichman leaves
* peichman joins14:59
* github-ff joins15:12
[fcrepo-specification] bbpennel opened pull request #224: Added text for HEAD and GET requests to LDPCv objects (master...223_ldpcv_get_head) https://git.io/v55ez
* github-ff leaves
* dwilcox joins15:15
<harringj2>apb18: PR is fixed, and when Travis is done, it should be all set15:19
<apb18>harringj2: Great, thanks! Will merge once Travis finishes successfully.15:21
* dwilcox leaves15:25
* github-ff joins15:26
[fcrepo-specification] bbpennel opened pull request #225: Remove section defining PUT operations for LDPRv's (master...215_remove_ldprv_put) https://git.io/v55fm
* github-ff leaves
* dwilcox joins15:49
* github-ff joins15:53
[fcrepo4] birkland pushed 1 new commit to master: https://git.io/v55TX
fcrepo4/master 5e7fff9 harringj: Adds support for depth headers to http DELETE method (#1237)...
* github-ff leaves
<harringj2>apb18: i could probably take https://jira.duraspace.org/browse/FCREPO-2609 if that would be helpful16:07
* escowles_ joins16:10
<apb18>harringj2: That would be great, especially before people start working on authz issues that will come out of the auth/versioning subroup
<harringj2>apb18: ++16:11
* dwilcox leaves16:12
<harringj2>it looks like the issue still needs to be opened, though
* github-ff joins16:13
[fcrepo-specification] bbpennel opened pull request #226: Added LDPRv PUT section for restoring a previous LDPRm (master...217_restore_version) https://git.io/v55IS
* github-ff leaves
* escowles leaves
* travis-ci joins
fcrepo4/fcrepo4#5151 (master - 5e7fff9 : harringj): The build passed.
Change view : https://github.com/fcrepo4/fcrepo4/compare/d94fd5a71927...5e7fff9e1b94
Build details : https://travis-ci.org/fcrepo4/fcrepo4/builds/276035063
* travis-ci leaves
* escowles_ leaves16:18
<bseeger>for the folks working on webac and moving it into core — by moving it, are we affecting software that might depend on it to build (outside of fedora4?)16:45
ie, fedora 4.7 maintenance branch?
or rather - does one generally leave it where it is but also copy it back into the code base?16:46
<apb18>bseeger: everything ought to be left where it is for maintenance of previous versions.16:58
I suppose it's an open question as far as keeping the webac code base in its own repo (and declaring it as a dependency), or moving it in.16:59
It's sort of the odd one out now.17:00
<bseeger>whikloj: webac question for you… :)17:01
<whikloj>bseeger: um ok
<bseeger>whikloj: did you guys implement acl:accessToClass in fedora?
whikloj: I'm looking at the code, but figured I'd ask as well.
<whikloj>bseeger: I believe so yes... though it was acoburn that did it. Let me have a look, its been awhile17:02
<bseeger>whikloj: it does look like you guys did17:03
<whikloj>bseeger: yeah, here https://github.com/fcrepo4/fcrepo-module-auth-webac/blob/master/src/main/java/org/fcrepo/auth/webac/WebACRolesProvider.java#L206
bseeger: for here https://github.com/fcrepo4/fcrepo-module-auth-webac/blob/master/src/main/java/org/fcrepo/auth/webac/WebACRolesProvider.java#L215
<bseeger>okay - thanks whikloj!17:04
<whikloj>bseeger: np
<harringj2>apb18: does the discussion above mean i should hold off on changes that would move webac into core?17:05
<apb18>maybe at least until we meet on Monday. but if you do have time to get a sense of the pros and cons of the two approaches, that would be great.17:06
<harringj2>i wasn't sure exactly what you meant by "it's an open question as far as keeping the webac code base in its own repo (and declaring it as a dependency), or moving it in"
ok, i'll proceed conservatively for the time being. have a great weekend!17:08
<apb18>harringj2, Good idea. The conservative stuff would still be useful if/when the more radical step of actually copying and mainintaining it in the codebase is taken17:09
have a good weekend all
* harringj2 leaves17:15
* apb18 leaves
* bseeger leaves17:24
* peichman leaves17:32
* whikloj leaves18:01
* mcritchlow leaves19:59
* yamil leaves20:09
* ff_logger leaves23:05
* lsitu leaves23:49
* lsitu joins23:50

Generated by Sualtam