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

Using timezone: Eastern Standard Time
* dwilcox joins02:21
* dwilcox leaves03:30
* dwilcox joins03:44
* dwilcox leaves03:46
* yinlin leaves05:33
* yinlin joins05:36
* benpennell joins08:44
* dwilcox joins09:08
* yamil_ joins09:14
* awoods joins09:15
* dwilcox leaves09:18
* dwilcox_ joins
* dhlamb joins09:43
* yinlin leaves09:47
* lsitu joins09:48
* bseeger joins09:50
<awoods>dhlamb/lsitu/dbernstein: are you planning on being on the Memento call in 9min?09:51
<lsitu>awoods: Yes, I’ll join.09:54
<bseeger>hi awoods - I'm on the call as well10:02
* ylchen joins10:03
* MartinKlein joins
<ylchen>Are tickets from FCREPO-2605 to FCREPO-2626 doable or still under discussion?10:07
"Bringing Web Time Travel to MediaWiki: An Assessment of the Memento MediaWiki Extension"
* dwilcox_ leaves
* dwilcox joins
<bseeger>part in the spec: http://fedora.info/2017/06/30/spec/#general-110:18
* whikloj joins10:40
* whikloj coming in late
<benpennell>whikloj: we are probably going to switch to 4.1.1 for datetime negotiation, due to content-location and caching recommendations10:41
<bseeger>whikloj: we're now talking about the scenario where the uri is versioned, then changes, changes some more and then is versioned again.10:42
whikloj: ie a webarchive scenario
versus a mediawiki scenario where every change is versioned
<benpennell>and if we should use the nearest memento or the nearest past memento
<bseeger>I really couldn't hear much of that at alll… the connection is kind of weired10:43
<MartinKlein>same here, sorry
<whikloj>bseeger: yes, so that was my understanding with client controlled versioning10:45
benpennell: that is interesting, moving to the closest version even if it is newer than requested10:47
<benpennell>whikloj: which might make sense in the use case of returning all mementos creating in a tree snapshot, since unless the client directly specifies the same memento-datetime, then some of the children mementos will be slightly in the future from the mementos further up the tree10:49
whikloj: but it is more predictable to do a nearest past memento
<whikloj>benpennell: right, so instead of "give me the version at least this old", we say "give me the version created around this date".10:50
<benpennell>yeah, which is the expected behavior in a webarchive apparently
<whikloj>benpennell: right, I wasn't even thinking about tree versioning. That does make sense especially in that context
<benpennell>they were warning about the unpredictability of nearest datetime algorithm10:51
<whikloj>how so?
better question10:52
is there someway to specify which datetime algorithm to use?
nearest versus closest older
<MartinKlein>another way to look at it: CMS, such as MediaWikis, for example, record history - create a snapshot for each version and with the nearest past memento algorithm you can be certain you get the version of a resource that was live at the requested datetime
web archives, OTOH, record observations, meaning they create snapshots whenever they discover/revisit a resource - there is no guarantee that you can obtain the version as it was at a specified time, hence the nearest memento (past or future) approach10:54
<benpennell>whikloj: there was some suggestion that people might select the algorithm they want. I wasn't clear on if that would be by implementation or by installation
<whikloj>MartinKlein: right right I can see those two being valuable but different. I think we definitely fall into the second group10:55
benpennell: that was what I was wondering about
benpennell: good example10:56
* dwilcox leaves10:57
<benpennell>whikloj: we are going to update the existing documentation and tickets to indicate use of negotiation pattern 4.1.1. I think any decision about picking an algorithm (min dist/min past) is a separate discussion that probably needs to be had10:58
<whikloj>benpennell: sounds good to me10:59
* ylchen leaves
<awoods>I have a call... then would like to circle up with the team11:00
benpennell: to confirm 4.1.1 was the 302 and Location header method right?
<bseeger>that was really great - I hadn't been thinking in terms of what wikimedia does versus webarchive11:02
and where we, as fedora, fall in that
<whikloj>yeah, it is a totally different perspective
<bseeger>or want to fall in that
* rotated8 joins
[API Alignment Standup]
Finished yesterday:
Nothing, had other meetings11:03
Working on today:
More testing
<whikloj>[API Alignment Standup]
Finished yesterday:
- nothing, took my kid to the doctor :)
Working on today:
- Unsure, I'm guessing still deciding on whether to use Modeshape or built versions explicitly11:04
- a decision to the above
<bseeger>whikloj: can mode shape version one object and stop there or does it have to do the ldp:contains?11:05
<whikloj>bseeger: https://github.com/fcrepo4/fcrepo4/pull/1250
Apparently lsitu figured it out
I'm going to build it right now
<bseeger>oh wow - that's great
<lsitu>whikloj: Yes. It works finally.11:06
<lsitu>[API Alignment Standup]11:07
Finished yesterday:
Support versioning with no versioned child: https://jira.duraspace.org/browse/FCREPO-2636
Tested and examined messaging in Assure that messages are emitted when required by the spec: https://jira.duraspace.org/browse/FCREPO-2604
Working on today:
Discussion of Version Implimentation.
Conclude test result for Assure that messages are emitted when required by the spec: https://jira.duraspace.org/browse/FCREPO-2604
Local meetings
* yinlin joins11:08
* MartinKlein leaves11:09
<yinlin>[API Alignment Standup]11:15
Finished yesterday:
Review tickets from FCREPO-2605 to FCREPO-2626 and also compare these tickets with https://wiki.duraspace.org/pages/viewpage.action?pageId=90964556
Working on today:
Identify workable tickets for implementation from FCREPO-2605 to FCREPO-2626. Otherwise, maybe pick up FCREPO-2606.
Can't tell which ticket is doable or is pending discussion on implementation. After attending today's Memento-WebAC-LDP Alignment meeting, it looks like still in pending discussion on implementation. Moreover, it looks like tickets are also depended on FCREPO-2634.
<awoods>whikloj/lsitu/bseeger/benpennell/yinlin/dhlamb/rotated8/dbernstein: would a quick call be useful now or later today/tomorrow?12:00
<whikloj>awoods: yes12:01
<benpennell>whikloj, bseeger, awoods: I have updated the tickets and confluence pages related to memento retrieval and datetime negotiation
<benpennell>to reflect use of algorithm 1.1
awoods: which specific topics would the call be about? I'm booked up until ~3pm today, tomorrow looks similar12:04
<whikloj>benpennell: we're trying to decide about modeshape versus all custom versioning. Pros and cons12:05
<dbernstein>morning all12:06
* bseeger leaves12:07
<whikloj>Also GETing the Memento of A referencing B once B is deleted. Because Fedora resolves the Node to get the Path...I think12:23
* lsitu leaves12:27
* lsitu joins
<yinlin>awoods: sure, when?12:32
<yinlin>awoods: update firefox..... join soon12:34
awoods: trouble shooting hangout, can't hear anything12:38
awoods: done. in the meeting now
* mcritchlow joins12:55
<whikloj>awoods: there was some confusion at the end, to confirm is the "custom" we are going with referring to "custom Modeshape versioning" or "completely custom versioning not using Modeshape's versioning functions"?13:19
<awoods>completely custom
<whikloj>awoods: ok, thanks13:20
lsitu: So I think we should leave your PR open for now, in case we run into trouble with completely custom.13:21
I'll pull down https://github.com/fcrepo4/fcrepo4/pull/1248 and if the normal tests all look good (except for versioning) I'll merge it and we can use that branch for our work.13:22
* benpennell leaves
<lsitu>whikloj: It sounds good.13:23
<whikloj>Then we can start with https://jira.duraspace.org/browse/FCREPO-2624 to enable versioning on a resource.13:25
Except that its not a POST, only a PUT with current body plus the new rdf:type13:27
oops I mean new header, not new rdf:type13:31
sorry I was on the wrong ticket, we have one for new objects (https://jira.duraspace.org/browse/FCREPO-2624) and one for old (https://jira.duraspace.org/browse/FCREPO-2625). Do you want to take those lsitu?13:33
Does it make sense to handle both together, or do you want to take one and leave the other for now?13:34
<lsitu>whikloj: Yes. I can.13:35
* benpennell joins13:36
* github-ff joins13:38
[fcrepo4] whikloj closed pull request #1248: FCREPO-2634. Removed versioning implementation code. (memento-versioning...memento-versioning) https://git.io/vdGkl
* github-ff leaves
<whikloj>I'm also going to throw this one out there https://jira.duraspace.org/browse/FCREPO-263813:47
* benpennell leaves13:52
* benpennell joins13:59
* bseeger joins
* bseeger leaves14:20
* travis-ci joins14:22
fcrepo4/fcrepo4#5192 (memento-versioning - 6a6ab26 : Jared Whiklo): The build passed.
Change view : https://github.com/fcrepo4/fcrepo4/compare/30b6e16fa5fb...6a6ab269857e
Build details : https://travis-ci.org/fcrepo4/fcrepo4/builds/282839750
* travis-ci leaves
<awoods>whikloj: I had the PR against Mohamed's memento branch:14:28
whikloj: see: https://jira.duraspace.org/browse/FCREPO-263414:29
<whikloj_AFK>awoods: odd, I did not get those build failures14:30
<awoods>whikloj: the build failures were fixed... but my PR reverted some of the code Mohamed removed.14:31
<whikloj>awoods: oh sorry, yes I see it
<awoods>whikloj: I can rebase my PR onto the memento branch... if you are will to merge
<whikloj>awoods: I was just going to suggest that
<awoods>whikloj: one moment14:32
<awoods>whikloj: I am building my cherry-pick locally...14:35
<whikloj>awoods: sounds good14:37
* github-ff joins14:42
[fcrepo4] awoods opened pull request #1251: Reintroduce Versioning placeholders (memento-versioning...fcrepo-2634.aw) https://git.io/vdlmf
* github-ff leaves
<awoods>whikloj ^^14:43
<whikloj>awoods: got it, thanks
awoods: you enabled Travis on the memento branch?14:56
<awoods>I can
<whikloj>awoods: it appears to be running on your PR14:57
<awoods>travis... yes, travis runs
I was thinking jenkins
<whikloj>awoods: ah ok, I didn't realize it was enabled for all branches
* travis-ci joins14:58
awoods/fcrepo4#16 (fcrepo-2634.aw - 30825e8 : Andrew Woods): The build passed.
Change view : https://github.com/awoods/fcrepo4/compare/6a6ab269857e^...30825e8791a2
Build details : https://travis-ci.org/awoods/fcrepo4/builds/282865906
* travis-ci leaves
* rotated8 leaves15:00
* rotated8 joins15:04
<dbernstein>whikloj et al: sorry to missed the delegation of issues after the google hangout memento discussion this morning. I’m available to pick up a couple of tickets. Any recommendations?15:12
* github-ff joins
[fcrepo4] whikloj pushed 2 new commits to memento-versioning: https://git.io/vdlst
fcrepo4/memento-versioning 30825e8 Andrew Woods: Reintroduce Versioning placeholders
fcrepo4/memento-versioning d09d92d Jared Whiklo: Merge pull request #1251 from awoods/fcrepo-2634.aw...
* github-ff leaves
<whikloj>dbernstein: not sure, lsitu is taking the tickets around getting versioning enabled on a resource (FCREPO-2624 and FCREPO-2625). You could work on...15:13
internal URI pattern - https://jira.duraspace.org/browse/FCREPO-263815:14
or building the LDPCv interactions...there isn't a ticket specifically (there are several) and you might want to work with lsitu as the LDPCv is created when versioning is turned on15:15
<lsitu>whikloj, dbernstein: I haven’t started on anytnig yet. Please feel free to take any tickets.
<whikloj>dbernstein: whatever you like then15:16
<lsitu>dbernstein: https://jira.duraspace.org/browse/FCREPO-2624, https://jira.duraspace.org/browse/FCREPO-262515:17
<dbernstein>lsitu, whikloj: cool thanks. I look at 2624 and 26525.15:19
[API Alignment Standup]15:22
Finished yesterday:
Feedback on PR for https://jira.duraspace.org/browse/FCREPO-2631
Enable WebAC by default
however disable WebAC in the one-click
Researched possibilities on https://jira.duraspace.org/browse/FCREPO-2630 (deploy time switch for web) and decided to punt for now.
Working on today:
Create deploy-time on/off switch for webac.
Enable versioning on new LDPR
Enable versioning on existing LDPR.
Resolve remaining conflicts on outstanding sprint 1 PRs.
* travis-ci joins15:31
fcrepo4/fcrepo4#5194 (memento-versioning - d09d92d : Jared Whiklo): The build passed.
Change view : https://github.com/fcrepo4/fcrepo4/compare/6a6ab269857e...d09d92d57f8c
Build details : https://travis-ci.org/fcrepo4/fcrepo4/builds/282878535
* travis-ci leaves
* mcritchlow leaves16:05
* mcritchlow joins16:07
* yinlin leaves16:29
* yinlin joins16:32
dbernstein: which document need to be updated in https://jira.duraspace.org/browse/FCREPO-2606 ?
<dbernstein>yinlin: good question: I will add a link to the jira. thanks for pointing that out!16:33
<yinlin>dbernstein: great! thx!
* yinlin leaves16:34
<dbernstein>yinlin: done!16:35
looks like there is no documentation for the current messaging features - https://wiki.duraspace.org/display/FEDORA4x/Event+Messaging16:36
* mcritchlow leaves16:37
* peichman joins16:56
* peichman leaves17:00
* dbernstein leaves17:02
* rotated8 leaves17:12
<lsitu>whikloj: Do we have any examples for Memento can we refernce during implementation?17:15
<whikloj>lsitu: like what headers to return? or what the body should look like?
<lsitu>whikloj: Yes.17:16
* peichman joins
<lsitu>whikloj: I can’t find any examples that shows all pieces together: WAC, container relationship, properties etc.17:18
* benpennell leaves
<whikloj>lsitu: yeah, we may not have all the headers in one place for a fedora resource because there could be such a variety17:19
* peichman leaves17:20
<whikloj>lsitu: For a memento you'd take the standard response. ie. for a RDFSource you have a body of serialized RDF, plus the LDP headers and (if applicable) ACL link header17:21
lsitu: and add an Accept-Datetime header, an "original" Link header a "timemap" link header
lsitu: and a "timegate" link header ( our original resource is our timegate, so this and the "original" link header point to the same place)17:22
<lsitu>whikloj: The body looks more important since https://jira.duraspace.org/browse/FCREPO-2624 and https://jira.duraspace.org/browse/FCREPO-2625 need to create Mementos, and other tickets may consume it.
<whikloj>lsitu: 2624 and 2625 are about updating the LDPR to a LDPRv and creating an associated LDPCv. Which body are we talking about?17:23
<lsitu>whikloj: “A LDPRm will be generated, contained by the LDPCv” in https://jira.duraspace.org/browse/FCREPO-2624 .17:24
<whikloj>lsitu: hmmm yeah, I think that is incorrect. According to the Fedora API spec you POST to the LDPCv to create a Memento. But perhaps I am misunderstanding.17:27
awoods: ^^
<whikloj>awoods: FCREPO-2624 indicates that PUT or POST to a LDPRv with a VersionedResource header, not only turns on versioning and creates a LDPCv, but it also creates a Memento?17:28
awoods: the Fedora spec only shows a PUT on an LDPRv for restoring a version.17:29
awoods: POST on LDPCv to create a Memento, is that your understanding. Could be the ticket description needs updating
<awoods>whikloj: right, I do not the process outlined in fcrepo-2624 should also create a memento17:30
whikloj: right, I do not think the process outlined in fcrepo-2624 should also create a memento
<whikloj>lsitu/awoods: I just updated the description of https://jira.duraspace.org/browse/FCREPO-2624, see if that seems better17:31
<lsitu>whikloj: https://jira.duraspace.org/browse/FCREPO-2625 the same.17:32
<whikloj>lsitu: yeah, I'll fix that too. I realize I keep removing POST in 2624, but that is about creating a new resource with versioning enabled
awoods: Also, lsitu and I had a quick discussion around being able to disable versioning without deleting all the versions. It might be worth while to consider a way to do that instead of deleting versions to turn off versioning.17:34
lsitu: updated FCREPO-262517:35
<lsitu>whikloj: ++
whikloj: What tickets are ready for me to work on now?17:36
<awoods>whikloj/lsitu: re: https://jira.duraspace.org/browse/FCREPO-2625 , I do not think we are talking about empty PUTs
<whikloj>awoods: I just updated that ticket to suggest sending the current body back in the PUT
<awoods>whikloj/lsitu: were there suggestions regarding other means of disabling versioning?17:37
<whikloj>lsitu/awoods: Not really, perhaps an alternate Header. The suggestion was that if you want to disable versioning but be able to turn it back on, then deleting all versions might be overkill.17:38
* awoods reviewing options in: https://tools.ietf.org/html/rfc5988
<whikloj>lsitu: Not sure, a lot rides on the LDPRv changes right now. You could start work on LDPCv interactions. Then dbernstein can incorporate your work into his?17:39
<lsitu>whikloj: Sure. Is there a ticket for it?17:40
<whikloj>lsitu: hmm there are a couple but maybe I'll make you a new one for the initial work17:41
lsitu: there is https://jira.duraspace.org/browse/FCREPO-2621 and https://jira.duraspace.org/browse/FCREPO-2623 but they are built on existing resources. You need to have a LDPCv resource first17:42
<lsitu>whikloj: I’ll take a look.
lsitu: https://jira.duraspace.org/browse/FCREPO-263917:45
until tomorrow......
* whikloj leaves
<awoods>whikloj: considering "Link: <> rel='nofollow'" https://www.w3.org/TR/html5/links.html#link-type-nofollow
* dhlamb leaves18:24
* yamil_ leaves18:42
* peichman joins19:01
* peichman leaves19:05
* rotated8 joins19:21
* dwilcox joins19:52
* dwilcox leaves20:31
* peichman joins22:49
* peichman leaves22:53
* awoods leaves23:17
* rotated8 leaves23:47
* peichman joins00:46
* peichman leaves00:51
* lsitu leaves00:57

Generated by Sualtam