Log of the #duraspace-ff channel on chat.freenode.net

Using timezone: Eastern Standard Time
* dwilcox joins07:14
<pivotal-bot>Esme Cowles estimated "Implement read-only FedoraRepository" as 1 point https://www.pivotaltracker.com/story/show/7710935007:37
Esme Cowles started "Implement read-only FedoraRepository" https://www.pivotaltracker.com/story/show/77109350
Esme Cowles added comment: "https://github.com/fcrepo4-labs/fcrepo4-client/pull/8" https://www.pivotaltracker.com/story/show/7710935008:16
Esme Cowles finished "Implement read-only FedoraRepository" https://www.pivotaltracker.com/story/show/7710935008:17
* github-ff joins
[fcrepo4-client] escowles opened pull request #8: Read-only repository implementation (master...read-only) http://git.io/oWzGJA
* github-ff leaves
<pivotal-bot>Esme Cowles started "Binary content resource impl" https://www.pivotaltracker.com/story/show/75053298
* mohamed joins08:26
* ksclarke joins09:23
* awoods joins09:24
* tecoripa joins09:34
* github-ff joins09:36
[fcrepo4] awoods pushed 1 new commit to master: http://git.io/MwIofw
fcrepo4/master db1180e Esmé Cowles: Make baseURLSet static to avoid running baseURL code with each request...
* github-ff leaves
<pivotal-bot>Andrew Woods added comment: "Resolved with: https://github.com/fcrepo4/fcrepo4/commit/db1180e899c3ad9bbb65dc2f226c86b1417df7d1" https://www.pivotaltracker.com/story/show/7749270209:37
* github-ff joins
[fcrepo4] awoods closed pull request #444: Making baseURLSet static to avoid running baseURL code with each request (master...static-baseURLSet) http://git.io/0Ck2lw
* github-ff leaves
<pivotal-bot>Andrew Woods delivered "OutOfMemoryError (running out of threads) after many updates" https://www.pivotaltracker.com/story/show/77492702
<f4jenkins>Yippee, build fixed!09:50
Project fcrepo4 build #2052: FIXED in 14 min: http://jenkins.fcrepo.org/job/fcrepo4/2052/
awoods: Make baseURLSet static to avoid running baseURL code with each request
* travis-ci joins09:53
[travis-ci] fcrepo4/fcrepo4#2239 (master - db1180e : Esmé Cowles): The build passed.
[travis-ci] Change view : https://github.com/fcrepo4/fcrepo4/compare/82a0596cb1ad...db1180e899c3
[travis-ci] Build details : http://travis-ci.org/fcrepo4/fcrepo4/builds/33491020
* travis-ci leaves
<f4jenkins>Project fcrepo-module-auth-rbacl build #41: UNSTABLE in 3 min 2 sec: http://jenkins.fcrepo.org/job/fcrepo-module-auth-rbacl/41/
* mohamed1 joins09:56
* mohamed leaves09:58
<f4jenkins>Yippee, build fixed!10:07
Project fcrepo-module-auth-rbacl build #42: FIXED in 3 min 15 sec: http://jenkins.fcrepo.org/job/fcrepo-module-auth-rbacl/42/
* scossu joins10:11
<awoods>escowles/cbeer: would you be interested and available for a Fedora-dev-team-meeting on Monday Sept 29th (the first day of Hydra-Connect)?10:12
<escowles>awoods/cbeer: i'm getting in to CLE around 4pm -- so 5/6pm would work for me (i don't have dinner plans yet either, but the wiki mentions forthcoming organizing of that a la code4lib)10:18
<awoods>escowles: Dinner is a great idea. We could chat some then. Hydra-connect is asking if we want to reserve a room on Monday... it sounds like "no".10:20
<pivotal-bot>Andrew Woods accepted "Implement core object handling" https://www.pivotaltracker.com/story/show/7710939810:21
Andrew Woods accepted "PowerMock / Java 1.7.0_65 incompatibility" https://www.pivotaltracker.com/story/show/77197212
Andrew Woods accepted "FedoraStoragePolicyTest.testDeleteNodeType()" https://www.pivotaltracker.com/story/show/77452936
Andrew Woods accepted "Enable Travis-CI on fcrepo4-client" https://www.pivotaltracker.com/story/show/77481930
Andrew Woods accepted "Increment version of fcrepo4-client to snapshot-beta-02" https://www.pivotaltracker.com/story/show/77482624
Andrew Woods added comment: "@justincoyne4, can you verify this fix?" https://www.pivotaltracker.com/story/show/77492702
* tecoripa leaves10:30
* tecoripa joins10:31
<escowles>awoods: sounds good -- i agree we don't need a room on monday, since we'll be a pretty small group something more informal would be fine.10:35
<awoods>escowles: +1
* barmintor joins10:37
<cbeer>awoods: i'm getting in on Tuesday, so no.11:15
<awoods>cbeer: thanks11:16
* Giulia joins11:25
* scossu leaves11:38
* scossu joins11:46
* mohamed1 leaves11:57
* mohamed joins12:15
<awoods>cbeer: Do you have the meeting minutes from: https://wiki.duraspace.org/display/FF/2014-08-20+-+Fedora+Technical+WG+Meeting12:42
<cbeer>awoods: notes are on the pages we discussed.
<awoods>cbeer: ok, thanks12:44
* scossu leaves12:55
* scossu joins13:01
<awoods>cbeer: can you verify escowles update for: https://www.pivotaltracker.com/story/show/7749270213:45
<pivotal-bot>bug: OutOfMemoryError (running out of threads) after many updates (delivered) / owner: Esme Cowles
<awoods>cbeer: it has been committed to "master"
escowles/cbeer: I am also interested in the issue jcoyne raised regarding etags: https://github.com/fcrepo4/fcrepo4/issues/44213:47
escowles/cbeer: is that issue something that you have run into or are concerned about?
<cbeer>awoods: if i understand what jcoyne is doing (and i'm not sure I do.. that report is very unclear), i'm not convinced its a bug.13:48
or, if it is, it is both not serious and not easy to fix.
<awoods>cbeer: is jcoyne on vacation?
cbeer: it would be good to get his clarification on that issue
<cbeer>if r2 adds a relationship to r1, in some types of requests, the response to a request for r1 will be different.
<awoods>cbeer: the etag seems to be based on the last-modified date13:49
<cbeer>and we're ETagging at the object level, not the response.
<awoods>cbeer: I would not expect the last-modified date to be updated based on his updates to /r2...13:50
<cbeer>awoods: if that's true, that's how modeshape has decided to etag them.
<escowles>awoods: i think i understand the scenario jcoyne is talking about: having a record that gets linked to from many other records (e.g. collection records, authority records, etc.)
<cbeer>awoods: except that the response for /r1 WILL be different, so the etag should be changed.
<escowles>if it's getting updated every time a new record links to it (and the etag changes because of that), that would be annoying, esp. since those are exactly the kinds of records you'd want to cache13:51
<cbeer>and, at the JCR level, both /r1 and /r2 are changed.
<awoods>https://github.com/fcrepo4/fcrepo4/blob/master/fcrepo-kernel-impl/src/main/java/org/fcrepo/kernel/impl/FedoraResourceImpl.java#L379
escowles: yes, that *seems* to be the scenario. I would be a little surprised if updates to /r2 are causing updates to /r1 in this case, however.13:52
<cbeer>awoods: but they DO cause updates.13:53
if you add a (strong) relationship between /r2 and /r1
you're adding a property on both r2 and on r1.
and, if you request /r1, your response may be different after you add that property13:54
so changing the etag is appropriate.
<escowles>cbeer: hypothetically, you could use the LDP headers to suppress links to the other resources, and then the content wouldn't change13:55
<awoods>cbeer: the relationship that is being created is "rels-ext#isTopicOf"
<escowles>so then it would be a nice improvement for the etag to not change either
<awoods>cbeer: I guess it depends on the property-type that jcoyne is defining on rels-ext#isTopicOf
<cbeer>escowles: you could, but, as I said, we're etagging based on the object, not the response content.13:56
<escowles>cbeer: right -- you'd probably have to have a separate somethingOtherThankReferencesLastModified property to handle that
<cbeer>escowles: and, if that's his use case, and he doesn't need any of the strong reference functionality, he should change his property type.
<awoods>cbeer: rels-ext#isTopicOf only changes the referenced object if the property-type is REFERENCE13:57
<escowles>so changing to WEAKREFERENCE would probably fix this
<cbeer>escowles: it would, but also sacrifices functionality and should not be our default.
<awoods>escowles/cbeer: assuming the issue we are discussing is indeed jcoyne's issue, the solution would seem to be updating our etag logic, having jcoyne update his property-types, or not providing a solution.14:00
<cbeer>and i am against changing our etag logic, and i'm not sure it needs a solution. if he's writing code that assumes nothing else is going to touch his objects, he's in for a bad time.
* bljenkins leaves14:02
* ff_logger leaves
<escowles>i agree with cbeer: clients should expect to see etag failures and reload records accordingly (that's what the etags are for)
<awoods>cbeer/escowles: In bringing this back to this week's beta-3 release, I am therefore only waiting on verification of escowles fix: https://www.pivotaltracker.com/story/show/7749270214:03
<pivotal-bot>bug: OutOfMemoryError (running out of threads) after many updates (delivered) / owner: Esme Cowles
* bljenkins joins14:07
<Giulia>Andrew, quick question RE: federation and repository.json to modify since several are in place. I assume it's the fcrepo-webapp/target/fcrepo-webapp-4.0.0-beta-02-SNAPSHOT/WEB-INF/classes/config/minimal/repository.json plus restart. Following the HowTo15:03
<awoods>Giulia: typically, I use the system property "fcrepo.modeshape.configuration" to point to the repository.json for the application to use: https://wiki.duraspace.org/display/FF/Application+Configuration#ApplicationConfiguration-configelements15:09
* dwilcox leaves15:34
* scossu leaves16:02
* scossu joins16:26
* mohamed leaves17:00
* scossu leaves17:41
* tecoripa leaves17:48
* Giulia leaves17:58
* awoods leaves18:13
* Giulia joins
* awoods joins18:26
* marvilekke leaves18:46
* marvilekke joins18:50
* Giulia leaves19:16
* scossu joins19:58
* scossu leaves19:59
* ff_logger joins22:58

Generated by Sualtam