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

Using timezone: Eastern Standard Time
* apb18 joins08:48
* whikloj joins09:02
* benpennell joins09:05
* dwilcox joins09:15
* yamil joins09:16
* bseeger joins09:18
* apb18_ joins09:49
* apb18 leaves09:50
* apb18_ leaves
* apb18 joins
* escowles joins09:57
* peichman joins09:58
<apb18>https://wiki.duraspace.org/display/FF/2017-09-11+API+Alignment10:02
* lsitu joins
<apb18>https://wiki.duraspace.org/display/FF/2017+API+Alignment+Sprint+0110:20
* zimeon joins10:21
<benpennell>yup10:22
<bseeger>abp18 - was this the page? https://wiki.duraspace.org/display/FF/Guide+for+New+Developers10:25
<escowles>bseeger: yep, i think that's the one
<apb18>https://wiki.duraspace.org/display/FEDORAAPI/Fedora+API+Delta+Document10:34
<bseeger>okay - that sounds good to me10:44
<escowles>i just created a "breaking-change" label in https://github.com/fcrepo4/fcrepo4/issues10:46
<bseeger>agreed - that process works for me10:47
* harringj joins10:49
<bseeger>yeah, maybe we don't have to go var with azn, just that we consider it design-wise10:56
/var/var
/var/far, that is
<escowles>bseeger: yep, i think doing the design up front would let us resolve issues before the next sprint, for example
* westgard joins
* peichman leaves11:01
<bseeger>sounds good to me as well11:02
<benpennell>apb18: I would actually be okay with looking at some of the messaging tasks, but it depends on how the versioning stuff goes, and I'm also interested in the external binary file uri changes11:08
<apb18>benpennell: Do you want to coordiante with lsitu for creating the task lists, or do you mean you'd be interested in *implementing* some of them after creating versioning tasks?11:10
<bseeger>yes, I think so11:20
<benpennell>Joe and myself won't be available wednesday morning, but either tuesday afternoon or wednesday afternoon is fine
<bseeger>I was thinking the same thing abp1811:21
<benpennell>tomorrow at 10am is fine with me
<harringj>ditto11:22
<westgard>I need to spend time with these sections of the spec first and foremost11:23
It might be good to have a confluence page where we could brainstorm issues
<bseeger>westgard, benpennell - me too.11:24
<apb18>https://wiki.duraspace.org/display/FF/2017+API+Alignment+Sprint+01
<harringj>escowles: how would you like to divvy up the ticket-creation for the CRUD?
<benpennell>bseeger, westgard: yes, i have a lot of reading to do as well11:25
<bseeger>benpennell, westgard - how about we have a phone call / google hangout this afternoon after we've had a chance to read some?
<escowles>it looks like the external content block is about half of the CRUD line items — so that vs. everything else?
<harringj>sure, sounds good. just say which you'd prefer, and i'll grab the other :-)11:26
<westgard>I can go ahead and create the versioning/auth confluence page. Call this pm sounds good. I'm blocked 2-4 ET, tho.
<escowles>harringj: ok, i'll do the external content ones then
<bseeger>benpennell, westgard - great - go for it. I'm avail up til 4 pm. We could touch base around 1 or 1:30 just to talk about initial ideas?11:27
<westgard>OK
<escowles>afk # lunch
<benpennell>okay, how about 1:30?
its already 11:30
<bseeger>:) yeah, it doesn't give us much time…11:28
1:30 sounds good.
<westgard>benpennell++ bseeger++
<bseeger>afk # lunch as well11:29
* benpennell leaves11:36
<apb18>API Alignment folks: I created an epic here https://jira.duraspace.org/browse/FCREPO-258211:41
.. so when we create tickets, select "API Alignment" as the epic11:42
* benpennell joins11:43
* bseeger leaves12:10
* zimeon leaves12:27
* harringj leaves12:28
<westgard>benpennell -- bseeger is away but I have just noticed that I have a 1:30 conflict. Perhaps as an alternative to a meeting we can record initial thoughts here?: https://wiki.duraspace.org/pages/viewpage.action?pageId=9096450712:50
<benpennell>westgard that works for me, we can check back in tomorrow for more discussion12:51
i'll try to let her know of the change12:52
<westgard>benpennell++ I need more time to gather my thoughts anyway
* benpennell leaves12:56
* harringj joins12:59
* bseeger joins13:04
* benpennell joins13:55
<escowles>btw, i've created a filter that lists all the JIRA tickets in the API Alignment epic: https://jira.duraspace.org/issues/?filter=1430214:06
<bseeger>escowles++
<apb18>escowles: It tells me it doesn't exist or is private14:07
<escowles>apb18: sorry, i think it's public now14:08
hmmm... let me see what i need to do to make it public14:09
ok, i think it's public now
<harringj>yep, i can see it14:10
<apb18>Great, I can see it now!
* westgard leaves14:11
* escowles leaves14:18
* escowles joins14:19
* peichman joins14:29
<lsitu>escowles: For Transmission Fixity, I see Fedora codebase is already done with 409 status for invalid checksums from the Digest header. So we don't need to do anything for it, right?14:59
For Persistence Fixity, it looks like we just need a ticket to support/respect the Want-Digest on HEAD and GET of LDP-NRs, and maybe another ticket to remove the current fixty check with adding "/fcr:fixity" to the end of the binary URL. Do I miss anything from the API spec?
<escowles>lsitu: that sounds right to me: i think you should update the Delta Document when there is actually no change we need to make15:00
<lsitu>escowles++15:01
<benpennell>escowles: I'm reading through the memento specification and trying to work out which datetime negotiation pattern the fcrepo specification and modeshape impl are following. I'm guessing from the fcrepo spec that it is one of the URI-R=URI-G ones?15:02
* dwilcox leaves
<escowles>benpennell: i think it's this one: https://tools.ietf.org/html/rfc7089#section-4.1.215:05
wait, wrong link: it think it's https://tools.ietf.org/html/rfc7089#section-4.2.215:07
so the main URI is the URI-R, fcr:versions is the URI-G, and each version is a URI-M15:08
<benpennell>escowles: oh, so URI-R is not the URI-G, I was confused by the line: A versioned resource for this document provides a https://fcrepo.github.io/fcrepo-specification/#dfn-timegate interaction model as detailed in the Memento specification [https://fcrepo.github.io/fcrepo-specification/#bib-RFC7089] and indicated by an HTTP header Link: rel="timegate" *referencing itself*.15:09
<escowles>benpennell: let me read that section again more closely
* peichman leaves15:11
* lsitu leaves
* lsitu joins15:12
<escowles>ok, so i think i was right the first time, and it should be https://tools.ietf.org/html/rfc7089#section-4.1.2 — the resource is its own timegate15:13
<benpennell>escowles: okay, thank you, just wanted to make sure I understood how the two specifications fit together before moving ahead15:15
does that imply that there isn't a fcr:versions endpoint anymore though?
<escowles>i think that fcr:versions is the TimeMap (URI-T) — it continues to list all the available versions15:17
<benpennell>ah ha, that makes sense
* dwilcox joins15:23
<benpennell>escowles: thanks again. i'm kind of glad its using that pattern, although i was wondering a bit after seeing a few tickets in the api spec closed issues about allowing both the client managed and server managed versioning (partially because I don't totally know what that means)15:27
<escowles>benpennell: server-managed means that the server creates versions for every change, client-managed means the client has to create the versions it wants15:28
<benpennell>escowles: ahh, okay, that makes sense and is pretty independent of the datetime negotiation stuff15:29
things are starting to fit together a bit better for me :)
<escowles>good! the memento stuff is pretty fiddly, and i forget it quickly if i'm not working with it all the time15:30
<benpennell>yeah, i'm probably going to have a hard time retaining it until its documented as concrete api calls rather than a couple of specifications15:31
* apb18 leaves15:46
<lsitu>escowles: I’ve created ticket https://jira.duraspace.org/browse/FCREPO-2601 for Persistence Fixity. But it looks like it’s overlapping with the ticket https://jira.duraspace.org/browse/FCREPO-2597 you created. Correct?15:58
* bseeger leaves
<escowles>yes, it's listed in both the fixity and CRUD sections - i'll close https://jira.duraspace.org/browse/FCREPO-2597 as a duplicate15:59
<lsitu>escowels: Thanks. Could you open either one so that I can work on it?16:00
* peichman joins16:01
<escowles>i've opened 2601 — do they not let you open them?16:04
maybe i'll go open all of them...
<lsitu>escowels++16:05
escowels: I see the Open button there. But it looks like the process requirs reviewing …16:08
* peichman leaves16:12
* peichman joins
* apb18 joins16:13
* peichman1 joins16:15
<apb18>escowles: Everything that is there is straightforward and should all be "open", thanks for doing that16:17
benpennell, escowles : Just out of curiosity, does the use of "Content-Location" as spelled out by Memento in https://tools.ietf.org/html/rfc7089#section-4.1.2 conflict at all with the use of Content-Location as it relates to external content in https://fcrepo.github.io/fcrepo-specification/#external-content?16:21
* cbeer_ joins
<escowles>maybe — i'm going to ask barmintor about that, and if i'm reading the spec correctly that 4.1.2 is the pattern we should be using16:23
* peichman leaves16:25
* cbeer leaves
<apb18>Great, thanks
<benpennell>it does kind of look like it, good catch apb18. pattern 1.3 wouldn't involve use of it for memento https://tools.ietf.org/html/rfc7089#page-1916:30
it does seem like Content-Location is just returned for HEAD/GET requests against LDP-NRs though, whereas it may be that LDP-RSs would return the memento header. it is rather confusing using it for two separate things on the same LDPR.16:36
<apb18>benpennell: 1.3 is interesting, trying to wrap my head around it. It would seem that a URI would be insufficient for, say, linking to a specific version of a resource?16:38
i.e. you'd need a URI and (separately) a time?16:39
benpennell: Yeah, at the very least confusing to have two different semantics for that header16:41
* yamil leaves16:42
<benpennell>apb18: i'm trying to work that out myself. there is still the timemap to figure out what the versions are, but given that there is no distinct URI-M it may be that the only way to request the older versions is by sending an datetime-accept header, which is a bit of a departure for regular fcrepo behaviors16:47
could just be that the current version uris still exist but you don't address the mementos that way through the api, even if you can still access them directly behind the scenes16:50
<apb18>benpennell: In any case, it's a good thing that we're doing a versioning design issues before creating tasks, so we can at least work out the issues "on paper" first and begin to understand the consequences and tradeoffs!16:51
<benpennell>yes, i'll be interested to know what barmintor or other people that worked on the spec think as well16:53
<escowles>ok, i think issue here is that the spec doesn't specify which of the 4.1.x patterns to use, because implementations can have different opinions on whether the versions have their own URIs17:06
so i think we could do any of the 4.1.x patterns that make sense17:08
i think 4.1.3 doesn't fit our implementation (because we have distinct URIs for the versions (URI-Ms))
<benpennell>that explains why the fcrepo spec seems a bit agnostic, even if its a bit confusing17:09
<escowles>barmintor notes that the Content-Location header issue could be resolved by doing a HEAD request on the URI-M without the Memento-Datetime header, or on the URI in the Content-Location header, in order to figure out if it was an external resource or not17:10
<apb18>escowles: Yes, I agree that we are free to pick a pattern that makes sense; versioning/auth subgroup makes sense to hash out details for a decision
anyway, I have to go pick up kids
See you all at meeting tomorrow: https://wiki.duraspace.org/display/FF/2017-09-12+Task+Creation+Update
<escowles>apb18++ # i'm heading out shortly too17:11
<harringj>escowles: are there any CRUD tickets you think might be good candidates for me to start working, i.e., any that are better intro-level tickets?17:12
<benpennell>escowles: so would we be potentially returning two Content-Locations on the same object and making clients make HEAD requests against both to determine which one they wanted?17:13
<harringj>i can also check with you in the morning, since i see that you're about to sign off
<escowles>harringj: i think 2600, 2593, and 2588 are all good ones to start with17:14
* apb18 leaves17:15
<harringj>escowles: thank you!17:18
* harringj leaves17:27
* peichman1 leaves17:42
* whikloj leaves18:08
* escowles_ joins18:19
* escowles leaves18:21
* dwilcox leaves20:17
* benpennell leaves23:00
* lsitu leaves23:05
* benpennell joins23:21
* benpennell leaves00:21