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

Using timezone: Eastern Standard Time
* dwilcox joins03:09
* dwilcox leaves03:19
* dwilcox_ joins
* dwilcox joins03:39
* dwilcox_ leaves
* dwilcox leaves04:19
* dwilcox_ joins
* dwilcox_ leaves04:34
* dwilcox joins05:00
* dwilcox_ joins05:05
* dwilcox leaves05:06
* dwilcox_ leaves05:09
* dwilcox joins05:34
* dwilcox_ joins05:37
* dwilcox leaves05:40
* dwilcox_ leaves05:43
* dwilcox joins05:57
* dwilcox_ joins06:01
* dwilcox leaves06:04
* dwilcox joins06:06
* dwilcox_ leaves06:09
* dwilcox leaves06:13
* awead leaves07:37
* awead joins07:38
* github-ff joins08:14
[fcrepo4] escowles created setURIProperty (+1 new commit): http://git.io/vfBTY
fcrepo4/setURIProperty 0a7b1d4 Esmé Cowles: Adding FedoraResource.setURIProperty method
* github-ff leaves
* github-ff joins08:16
[fcrepo4] escowles opened pull request #781: Adding FedoraResource.setURIProperty method (master...setURIProperty) http://git.io/vfBkf
* github-ff leaves
* dhlamb joins08:21
* travis-ci joins08:32
fcrepo4/fcrepo4#3610 (setURIProperty - 0a7b1d4 : Esmé Cowles): The build passed.
Change view : https://github.com/fcrepo4/fcrepo4/commit/0a7b1d476260
Build details : http://travis-ci.org/fcrepo4/fcrepo4/builds/59711718
* travis-ci leaves
<f4jenkins>Project fcrepo-camel-toolbox build #43: FAILURE in 2 min 23 sec: http://jenkins.fcrepo.org/job/fcrepo-camel-toolbox/43/08:39
Yippee, build fixed!08:42
Project fcrepo4-release-tests build #195: FIXED in 1 min 50 sec: http://jenkins.fcrepo.org/job/fcrepo4-release-tests/195/
* acoburn joins09:11
* ksclarke joins09:12
* acoburn leaves09:17
<ruebot>do we have a tech meeting today? i don't see a page for it.09:29
* awoods joins09:36
* doylejo joins
* acoburn joins09:40
* doylejo leaves09:45
* MohamedAR joins09:51
<escowles>ruebot: yes we do -- i'll make the page...10:04
ruebot: i see you and awoods are way ahead of me
<awoods>Hi team. I am back for a day or two.10:05
<escowles>awoods: welcome back!10:06
<awoods>escowles: thanks for doing your magic with the audit service.
escowles: Did you see this comment from last night? https://github.com/fcrepo4-labs/fcrepo-audit/commit/3d7d6d348424df73940bf992b2770cdbc92dc3d5#commitcomment-1086012410:07
<escowles>awoods: yep, see my replies and https://jira.duraspace.org/browse/FCREPO-1489
<ruebot>escowles++ awoods++10:08
* ajs6f joins10:18
* barmintor leaves10:20
* github-ff joins10:27
[fcrepo4] escowles pushed 1 new commit to setURIProperty: http://git.io/vfBp8
fcrepo4/setURIProperty d6acc3e Esmé Cowles: Updating the javadoc comment to indicate how the setURIProperty differs from other functionality, and what the tradeoff is
* github-ff leaves
<ajs6f>awoods: was that LDP message a report of a presentation that is available somewhere?10:31
<mikeAtUVa>ruebot, dhlamb: I'm off tomororw... should we do a migration-utils update today sometime or wait until next Friday? In general, my update would be that I'm going to pull in dhlamb's PR/6 once I test it against an actual RELS-INT datastream... I made a bunch of tickets for small issues and I'll likely work a few of them before next Friday. Also, nianli discovered some issues that we'll have tickets for soon.
<awoods>ajs6f: the presentation was only verbal. No slides.10:32
<ajs6f>K
<ruebot>dhlamb: do you have time later today if you want to meet? all i have is the islandora committers call at 2pm EDT.10:33
<ajs6f>awoods: did they buy the idea of an extension mechanism?
<awoods>ajs6f: They did. It is number one on the 5 priorities for the next LDP charter.10:34
* whikloj joins10:36
<dhlamb>ruebot: mikeAtUVa: i'm on a call from 3:00-4:00 AST, other than that i'm free10:37
<ajs6f>awoods: superb.10:38
<awoods>ajs6f: you will be on the tech call, right?10:40
<ajs6f>awoods: for some of the time. Why?10:41
* travis-ci joins
fcrepo4/fcrepo4#3612 (setURIProperty - d6acc3e : Esmé Cowles): The build passed.
Change view : https://github.com/fcrepo4/fcrepo4/compare/0a7b1d476260...d6acc3e789f3
Build details : http://travis-ci.org/fcrepo4/fcrepo4/builds/59729462
* travis-ci leaves
<awoods>ajs6f: jcoyne wanted to discuss bnodes... see: [hydra-tech] nested RDF attributes10:42
<ajs6f>awoods: we already had that discussion on the actual Fedora list.10:44
awoods: that sounds like a really poor use of time
<awoods>ajs6f: getting people on the same page is a good use of time.10:45
<ajs6f>awoods: i would be astonished if that happens10:46
<escowles>ajs6f: how difficult would it be to make the skolem/true-blank-node behavior a runtime option?10:49
<ajs6f>escowles: no idea. Sounds like a very bad move, for all the reasons already discussed10:50
<escowles>ajs6f: the alternative is to tell jcoyne and anyone else to skolemize their bnodes before sending them to the repo, which is fine IMO, but it was a nice feature (for them) to do it for them10:52
<awoods>escowles: are are still skolemizing user bnodes, we just aren't publishing them as first class resources.10:53
escowles: we are still skolemizing user bnodes, we just aren't publishing them as first class resources.
<escowles>awoods: we're deskolemizing them on output, right?10:54
<awoods>escowles: yes10:55
<escowles>awoods: so the skolemization is hidden from them now, but maybe we could expose it...10:56
<f4jenkins>Yippee, build fixed!
Project fcrepo-camel-toolbox build #44: FIXED in 4 min 30 sec: http://jenkins.fcrepo.org/job/fcrepo-camel-toolbox/44/
<ajs6f>escowles: it's pretty clear that jcoyne isn't asking for skolemization at all.. He's asking for some kind of auto-create facility.
Using skolemization to impl that function would be badly wrong. If that's a function that is wanted, we should address it as a new thing10:58
I'm in the call.10:59
* doylejo joins11:00
<f4jenkins>Project fcrepo4-release-tests build #196: FAILURE in 2 min 36 sec: http://jenkins.fcrepo.org/job/fcrepo4-release-tests/196/11:02
* acoburn1 joins11:04
* acoburn leaves11:06
* yinlin joins
* gregjansen joins11:14
* barmintor joins11:16
<gregjansen>Hello Fedora! I have a json-ld question. When doing a PUT in application/ld+json is any particular compact/expanded form required? Do urls for properties have to be registered in advance?11:17
<barmintor>awoods: sorry I’m late, our repo is having SWORD problems this morning.
<awoods>https://wiki.duraspace.org/display/FF/2015-04-23+-+Fedora+Tech+Meeting
<gregjansen>nm, my ld+json works now11:31
the answer: all forms I tried worked after I fixed a @type property11:34
<escowles>gregjansen++11:35
* awoods leaves11:39
<ajs6f>HTTP++
<ruebot>ajs6f's proposal makes sense to me11:40
<barmintor>ajs6f++11:42
winner winner
<ajs6f>Bum rush the LDP show.11:43
<mikeAtUVa>awoods: yeah, I'm here.11:47
* awoods joins11:51
* awead leaves12:06
* doylejo leaves
<awoods>gregjansen: many of us were on the tech call...12:07
* yinlin leaves
<awoods>gregjansen: it sounds like you are sorted, however.
<gregjansen>awoods: thx, yes I figured that
awoods: yes, my example search data is loading now12:08
<awoods>gregjansen: great
<acoburn1>awoods: my staff meeting was cancelled, so I can join this afternoon's meeting12:13
awoods: is it via google hangout?
<awoods>acoburn1: great. yes, g-hangout
<ruebot>awoods: if you have some time, mind letting me know if this looks sane? https://raw.githubusercontent.com/wiki/Islandora-Labs/islandora/images/Islandora-PCDM-Fedora4.jpg12:14
<escowles>acoburn1: MohamedAR: I created tickets for writing the docs: https://jira.duraspace.org/browse/FCREPO-1494 and https://jira.duraspace.org/browse/FCREPO-1495
acoburn1: I also wonder if you could setup the InternalAuditor IT (https://jira.duraspace.org/browse/FCREPO-1481) which would free up awoods to do the reviewing work?12:15
<awoods>escowles: looking out for me. thanks ;)12:16
<acoburn1>escowles: sure, all three of this afternoon's meetings were cancelled, so I've got some extra time
<awoods>ruebot: it looks sane... but what I do not see are the relationships between the different resources, which may drive the decision on the type of containers you use.12:17
acoburn1: was there a disaster?
<escowles>awoods: i think you have a different definition of "disaster" than i do...12:18
<acoburn1>awoods: I certainly don't think of it as a disaster
awoods: mostly a bunch of people are on vacation
<ruebot>awoods: ah, ok. so basically something like what you've done here: https://wiki.duraspace.org/download/attachments/68067286/ldp-pcdm-f4-0.png?version=1&modificationDate=1428439557415&api=v212:19
* gregjansen leaves
<awoods>acoburn1: as long as the people who were supposed to be on the call still exist...
* ajs6f leaves12:20
* awead joins12:22
<awoods>ruebot: yes
acoburn1: I put your name on: https://jira.duraspace.org/browse/FCREPO-148112:26
<ruebot>awoods++ #thanks!12:27
* ajs6f joins12:32
<ruebot>awoods: https://www.dropbox.com/s/tbmvb8sq93d4x35/Islandora-PCDM-Fedora4.jpg?dl=012:33
...and acoburn1: i suppose this provides and opportunity to flesh out the relationship between the OBJ (tiff) and the TECHMD file.
<awoods>ruebot: you may want to use DirectContainers in all of your cases instead of BasicContainers...12:34
ruebot: so that the pcdm:* relationship would be auto-created for you.
<ruebot>awoods++
awoods: including the pcdm:Object -- the photo of elvis?12:36
* awead leaves12:48
<terrellt>I've been posting this in #projecthydra, but I think it's relevant here12:53
https://gist.github.com/terrellt/0b20b96304a24477a50212:54
We're sure indirect containers work right?
<awoods>terrellt: IndirectContainer did not work correctly until Fedora 4.1.0. Which version are you using?12:56
<terrellt>uh12:57
I dunno
How do I find out
<awoods>terrellt: sorry, I mean "until 4.1.1"
terrellt: can you go to the Fedora HTML UI?12:58
<terrellt>Yeah
* dwilcox joins
<awoods>terrellt: localhost:8080
<terrellt>I can go to the HTML REST UI if that's what you mean
Ah12:59
Here we go
4,9,9
*4.0.0
Okay, thanks.
<awoods>terrellt: you will want to be on 4.1.1
terrellt: https://wiki.duraspace.org/display/FF/Fedora+4.1.1+Release+Notes
<terrellt>awoods++13:00
<acoburn1>ajs6f: question about bnodes
ajs6f: I just built from master, and if I add a bnode to a container, and then try to view that container in the HTML interface, I get a bunch of exceptions13:01
using curl works fine
stack trace is here: https://gist.github.com/acoburn/c9ea7e75d565024401c313:04
<ajs6f>Sounds like a bug: something to do with assumptions that no longer apply?
We have no real testing for the HTML.13:05
<acoburn1>another related question, is the serialized bnode supposed to contain all the extra (server-managed) properties: fedora:Skolem, fedora:Resource, etc13:06
for example: https://gist.github.com/acoburn/81379477dad80c3f5b2b shows the PATCH request and GET response13:07
<ajs6f>No. It's exactly NOT a resource of the kind that is identified by an URI.
<acoburn1>so, all the jcr stuff should not be part of the serialization?13:08
<ajs6f>What do you mean by JCR stuff?
<acoburn1>_:gen1 a <http://www.jcp.org/jcr/nt/1.0folder> , <http://www.jcp.org/jcr/nt/1.0hierarchyNode>13:09
<ajs6f>No, those things are true. Why would we not publish them?13:10
<acoburn1>right, I just wanted to make sure that was part of the design
<ajs6f>Unless you want to not publish then about URI-resources either.
* awead joins13:11
<ajs6f>We are a bit schizophrenic about JCR types.
<acoburn1>but wouldn't the bnode /not/ be a <http://www.jcp.org/jcr/mix/1.0referenceable>
well, it is in the jcr layer, but not really in the fedora layer13:12
I don't have an opinion one way or the other, I just didn't expect to see all of the extra properties13:13
<ajs6f>No. It is reference-able from its parent and siblings. If that isn't your interpretation of that mixin, fine, but we'll need to check a lot of other places.
* jgpawletko joins13:14
<awoods>acoburn1: can you create a bug ticket for the bnode/HTML error?
<acoburn1>awoods: sure
<ajs6f>I have no strong feelings about it either. Bnodes are shit and the less work we waste on them the better.
<acoburn1>ajs6f++13:15
<ajs6f>Sorry about the HTML problem. I always forget to check that.
<acoburn1>awoods: https://jira.duraspace.org/browse/FCREPO-149613:20
<terrellt>I should really start mentioning this stuff here.
<awoods>terrellt: We don't know what we are missing.13:21
<terrellt>So I can ask for inbound relations on the node that's the object of an indirect relationship and I get the indirect container relation, but NOT the relation the indirect container created on a node.
<awoods>acoburn1: can you add example RDF to that ticket to make it easier for someone to replicate?13:22
<terrellt>So I get <http://localhost:8983/fedora/rest/test/1/members/46/65/55/55/46655555-a7d6-46cd-acf7-7cf0af8ea390> ns001:proxyFor <http://localhost:8983/fedora/rest/test/2> ., but not <http://localhost:8983/fedora/rest/test/1> ns00x:hasMember <http://localhost:8983/fedora/rest/test/2>
<acoburn1>awoods: sure
<whikloj>awoods: minutes are up, sorry if I missed anything.
<awoods>whikloj++
* MohamedAR leaves13:24
<awoods>terrellt: you are performing a GET on "/test/2" with the Prefer header specifying InboundReferences?13:26
<terrellt>Yes.
One second.
awoods: f
Bah13:27
https://gist.github.com/terrellt/bfaa82d74f42746a2140
I should probably include /113:28
Updated gist to show the relation on /test/113:30
* jcoyne joins13:31
* dwilcox leaves13:32
<awoods>terrellt: I suspect the issue is due to the fact that the membership relations are created on-the fly during the response creation, and are not managed within the JCR...
terrellt: whereas the JCR managed relations are what are used to determine "inbound references".13:33
<terrellt>Er, yikes, I should probably check the etags for /test/1 then.
<awoods>ajs6f/acoburn1: I think the following ticket is a blocker for 4.2.0: https://jira.duraspace.org/browse/FCREPO-149613:36
<acoburn1>awoods: I agree13:37
<terrellt>Etag Before Indirect Relationship: 48ac7a6505f22659fa7da0ec45c683d5$35e7916, after: 48ac7a6505f22659fa7da0ec45c683d5$35e7916
That's a problem too.
<awoods>terrellt: those etags seem very similar
<ajs6f>Why?
<terrellt>They're the same.13:38
<awoods>ajs6f: because they are the same
<ajs6f>Did you actually change that resource?
<terrellt>A triple was asserted on it by an indirect container - its representation is different now.
But the cache will fail if it depends on etags.
<ajs6f>Or its parent?
I'm not interested in represent ations here, but resources.13:39
<terrellt>ajs6f: https://gist.github.com/terrellt/74d618ec8b6d71859c1213:40
<ajs6f>It is radically unrealistic to suppose that a repo will update its etag for something because somewhere else in the world, someone asserted a relations hip to that resource.13:41
<terrellt>Two different response bodies, one etag.
I may have a fundamental misunderstanding about the purpose of an etag, if so I apologize.
<ajs6f>Let me repeat myself: I don't care.
Or maybe I do. I still don't care.13:42
We cannot make this kind of promise in an OWA world.
<terrellt>That's fine. Should probably document somewhere that caches are unreliable in the case of indirect containers.
<ajs6f>Sure-- absolutely.13:43
Or maybe I'm totally wrong. That should also be documented.
<terrellt>ajs6f++13:44
<acoburn1>http 1.1 spec on etags: http://tools.ietf.org/html/rfc7232#section-2.3
the spec claims etags are about representations (as opposed to resources)
<ajs6f>I am clearly wrong.
That is going to be a horrible ticket. Glad I'm not going to do it.13:45
<whikloj>ajs6f: I'll add that to the docs
<terrellt>If I can figure out Jira I'll post a couple tickets.
Want me to include the gists with those HTTP logs?
<awoods>terrellt: please do include the gists in your tickets.13:46
acoburn1: how do you feel Prefer headers play into etag/representations?13:47
acoburn1: different Prefer headers will return different representations.
<barmintor>I’m kind of with ajs6f if the problem is changes in the representation of inbound proerties
<awoods>acoburn1: however, the etag is being generated on the modifiedDate of the resource.
<ajs6f>Isn't that addressable with Vary:?
<acoburn1>awoods: a good caching proxy will manage that just fine13:48
<ajs6f>Acoburn: will we?
<awoods>the question I have is, should different representations based on Prefer header come with different etags?13:49
<ajs6f>We will give the same etag for different representation s.
<terrellt>awoods: The spec says yes.
<ajs6f>awoods: they must, on our reading of HTTP
<barmintor>that is an impossible task
<terrellt>Then don't send an etag/13:50
<whikloj>at the very least shouldn't we produce a Weak ETag?
<ajs6f>But we don't do that, now
barmintor++
<awoods>terrellt: we have to send etags
<terrellt>Weak etags could work.
<ajs6f>Or what?13:51
<terrellt>I'm not sure how flexible semantic equivalence is.
<barmintor>like, don’t send etag for some Prefer headers?
<ajs6f>That's at our discretion, intentionally
<terrellt>Or send a weak etag.
<whikloj>barmintor++13:52
<awoods>ldp-spec: http://www.w3.org/TR/ldp/#ldpr-gen-etags
which only specifies HEAD
no...
<whikloj>weak ETag is is
<barmintor>no, it’s all of them13:53
<acoburn1>also resources that contain representations
<barmintor>just HEAD in addition to the others
<awoods>barmintor: right, "for responses that contain resource representations or successful responses to HTTP HEAD requests."
<ajs6f>We don't have to do anything here, but we must do all we can.
<awoods>ajs6f: the question is, what is our target
our goal
<ajs6f>I don't understand the question13:54
<terrellt>I'd be cool with indirectly contained resources not generating etags too.
<awoods>ajs6f: like due to a misunderstanding on my part of your statement.
ajs6f: likely due to a misunderstanding on my part of your statement.
<acoburn1>the http spec uses the phrase "the selected representation, as determined at the conclusion of13:55
<terrellt>Created https://jira.duraspace.org/browse/FCREPO-1497 and https://jira.duraspace.org/browse/FCREPO-1498
<acoburn1> handling the request"
<awoods>terrellt: "not generating etags" or not having their etags updated?
<acoburn1>which seems to give us some room to determine what that means
<barmintor>do the strong ETags we send now vary by representation?
<terrellt>awoods: Bad etags are worse than no etags.
<ajs6f>My statement was bizarre and awkward. That was my intention and pleasure.
<barmintor>ajs6f+-
<ajs6f>barmintor: not by Prefer13:56
<barmintor>awoods: I can’t remember, but if I ask for turtle do I get a different ETag than if I ask for NTriples, for example?
<awoods>in a streaming response scenario, calculating etags on the representations is close to impossible.
barmintor: no
<ajs6f>barmintor: no
<awoods>barmintor: double no13:57
<ajs6f>Only lastmodified matters.
<barmintor>right, so, they’re really already broken
<ajs6f>Yes, they are.
<whikloj>wasn't there a ticket about this way back?
<ajs6f>I thought they were ok when i thought etags were for resources.
<barmintor>they should vary by response format, and if they include inbound properties they should be weak
<ajs6f>They are for representation s, but ours aren't.13:58
Weak or absent.
<barmintor>and people should know that preferring inbound triples means that you can’t cache
<terrellt>Ideally caching mechanisms should know.
<awoods>barmintor: what I am wondering is how to create an etag if there is no canonical representation even for the same serialization.13:59
<barmintor>ajs6f: I think this use case lines up with the definitions of weak validators
<ajs6f>Yes. That commonsensical
<terrellt>So like, if I want to put varnish in front it should probably be able to talk right.
<acoburn1>terrellt: yes, varnish can be configured to partition by prefer headers
<ajs6f>barmintor: eh? You mean in case of conflict?
<barmintor>awoods: hash the prefer header and the lastModified
<terrellt>^14:00
That solves the prefer piece.
<ajs6f>And transaction id.
<barmintor>awoods: although last modified has to be calculated according to included contained resources, too
<ajs6f>Got to hash that too.14:01
<terrellt>Transaction ID?
<awoods>terrellt/barmintor: may as well hash the content-type as well.
<acoburn1>the etag hash would also need to be based on an accept header
<terrellt>Heh.
<barmintor>ajs6f: yes, that is true- if you’re in the midst of a txn lastMod could be deceptive
<terrellt>Alright guys, etag = sha(rand(1,10000000000))
<barmintor>perfect14:02
<ajs6f>Can a representation vary by auth id?
<barmintor>hold on- how does the accept header come into play?
<terrellt>Chosen representation at least.14:03
<acoburn1>whether it is turtle or n-triples, for instance
<ajs6f>Better content-type than accept, no?
<terrellt>^
<acoburn1>yes
<barmintor>yeah
<awoods>yep14:04
<ajs6f>What about lastmod? Does it have to change with changes to contained things?14:05
<barmintor>“awoods: although last modified has to be calculated according to included contained resources, too"
<ajs6f>I sincerely %%6&:$45-; hope not.
Why?
<barmintor>if your response includes the contained things, the representation changed14:06
<terrellt>ajs6f: Not by representation, I think, but I'd expect it to change for the indirect containment case.
<ajs6f>This may not work. I'm starting to want drop etags for indirec containers
<barmintor>wait, wait: do we not include contained resources by default?
<terrellt>barmintor: ldp.contains?14:07
<barmintor>terrellt: yes
<terrellt>It does, I think.
And I think the etag changes.
<barmintor>so then lastMod for the container changes if you modify a contained resource
<terrellt>Maybe I'm crazy.
Woah, what
The representation doesn't include the triples in the contained resource
I don't think14:08
<awoods>if you add/remove contained resources, the etag changes.
<barmintor>for purposes of ETag calculation
<terrellt>The representation of the parent doesn't change if its children do, no?
<ajs6f>Does the jcr do that for us?
<barmintor>where’s that darn demo URL14:09
<awoods>http://futures6.fcrepo.org:8080/fcrepo/
<acoburn1>if you modify a child, the parent doesn't change
if you add/delete a child, the parent does change14:10
<awoods>acoburn1: right
<acoburn1>if you add/delete a child of the child (a grandchild), the original parent does not change14:11
<ajs6f>CONSISTENCY!!!
* github-ff joins
[fcrepo4] awoods pushed 1 new commit to master: http://git.io/vf0i5
fcrepo4/master fcec104 Andrew Woods: Merge pull request #779 from fcrepo4/tombstone-deskolemizing-error...
* github-ff leaves
<barmintor>I thought that the default serialization included properties of the contained resources
<awoods>barmintor: no, only a listing of those contained resources.14:12
<barmintor>ok
<acoburn1>the child properties are included with a fedora:EmbedResources prefer header14:13
<barmintor>ok, so that can’t be strongly validated
unless the lastMod of all the included resources is calculated14:14
<awoods>barmintor: and scossu is asking for a further extension of including properties with: https://jira.duraspace.org/browse/FCREPO-1364
<ajs6f>To see the world in a grain of sand...14:15
* github-ff joins14:19
[fcrepo4] cbeer deleted tombstone-deskolemizing-error at 94f0694: http://git.io/vf0M8
* github-ff leaves
<awoods>Were their other variables we wanted to include in determining etag besides:14:20
- content-type
- prefer
- last-modified
<terrellt>etag="w/wegaveup"
<barmintor>terrellt: you left off the timestamp14:21
<ajs6f>Phase of the moon
<terrellt>Just hash the body and call it a day.
<awoods>What did we decide on IndirectContainer relationships?14:22
<terrellt>You -have- to send an etag apparently.
So send a weak one maybe?
I don't know.
<barmintor>I mean, technically you would also want the impl version hashed in case a cache was running across a software upgrade
<terrellt>barmintor: Ahaha
I'm gonna go eat lunch, I trust you all.14:23
Cache the world.
<barmintor>you oughtn’t, it appears
<ajs6f>I vote to disable it for and write a ticket to figure out how to do it right.
<terrellt>ajs6f: You break LDP spec. =(
<awoods>ajs6f: could you repeat your thought?
<ajs6f>No. Just etag = random uuid14:24
<terrellt>Ah.
<acoburn1>you could just turn the current behavior into a weak etag for now
* travis-ci joins
<terrellt>Oh
<travis-ci>fcrepo4/fcrepo4#3614 (master - fcec104 : Andrew Woods): The build passed.
Change view : https://github.com/fcrepo4/fcrepo4/compare/48610ce62e33...fcec1046e2cd
Build details : http://travis-ci.org/fcrepo4/fcrepo4/builds/59764565
* travis-ci leaves
<terrellt>Wait
<barmintor>just make the current imple weak validator for everything but nonrdf unti we get it sorted
<terrellt>You can't do that.
<ajs6f>We don't know how to do it right.
<terrellt>That makes resources un-updatable.
Fedora will yell at me that the etag I sent is wrong
<ajs6f>The first thing is to stop doing it wrong.
<terrellt>barmintor++14:25
<ajs6f>Okay, a monotonically increasing value, updated per request,.
<terrellt>You could do that
<ajs6f>Whatevs. Just stop pretending that we're doing it.14:26
Doing it right, ie.
* github-ff joins14:27
[ontology] awoods pushed 1 new commit to master: http://git.io/vf097
ontology/master c77d81b Esmé Cowles: Add resourceModification supertype of contentModification and metadataModification...
* github-ff leaves
* github-ff joins14:28
[ontology] awoods deleted audit-ontology-update at 8c2a16f: http://git.io/vf0H8
* github-ff leaves
<f4jenkins>Project fcrepo4-oaiprovider build #223: UNSTABLE in 2 min 8 sec: http://jenkins.fcrepo.org/job/fcrepo4-oaiprovider/223/
Yippee, build fixed!14:46
Project fcrepo4-oaiprovider build #224: FIXED in 3 min 13 sec: http://jenkins.fcrepo.org/job/fcrepo4-oaiprovider/224/
* gregjansen joins14:48
* gregjansen leaves
<f4jenkins>Project fcrepo-audit build #1: SUCCESS in 1 min 45 sec: http://jenkins.fcrepo.org/job/fcrepo-audit/1/14:55
Yippee, build fixed!14:59
Project fcrepo4-release-tests build #197: FIXED in 1 min 36 sec: http://jenkins.fcrepo.org/job/fcrepo4-release-tests/197/
* ksclarke leaves15:01
* ksclarke joins15:03
* awoods leaves15:24
* awoods joins15:25
sorry: acoburn1, I dropped15:53
<acoburn1>question for you about the module naming in fcrepo-camel-toolbox
<awoods>yes15:54
<acoburn1>seemed that you had some suggestions?
<awoods>acoburn1: what is your suggestion?
<acoburn1>my only real suggestion was to prefix the modules with fcrepo-
but it seemed you had some thoughts on the package namespaces?15:55
currently everything is under org.fcrepo.camel.15:56
<awoods>acoburn1: right now we have:
- audit-triplestore-web
- audit-triplestore
- indexing-solr-web
- indexing-solr
<acoburn1>and indexing-triplestore / indexing-triplestore-web on the way
the package namespaces are, for instance:15:57
org.fcrepo.camel.audit.triplestore
<awoods>acoburn1: I would suggest we determine if the current 4 (soon to be 6) modules are well-named...
acoburn1: then ensure that the packages are aligned with those names.
<acoburn1>org.fcrepo.camel.indexing.solr
I have no particular attachment to the current naming scheme15:58
<awoods>acoburn1: Do you feel like the current names are concise and accurate?
acoburn1: I have another call...15:59
<acoburn1>the current scheme is based on the idea of: <function>-<backend>
<awoods>acoburn1: let's assume the current modules are well-named16:00
acoburn1: what did you have in mind for the package names?16:01
<acoburn1>again, the same principle
* MohamedAR joins
<acoburn1>we could shorten "indexing" to "index"
<awoods>acoburn1: and currently the package names do not follow that principle?
<acoburn1>they do, all under the org.fcrepo.camel namespace16:02
they are all part of the org.fcrepo.camel groupId
with the namespace being org.fcrepo.camel.<function>.<backend>
so: org.fcrepo.camel.audit.triplestore16:03
that way, there could be a org.fcrepo.camel.audit.cassandra project
using a cassandra backend
<awoods>acoburn1: the only option I see there is dropping "camel"... but I like the full org.fcrepo.camel prefix.
acoburn1: so your suggestion is to simply update the module names with an additional "fcrepo-" prefix?16:04
<acoburn1>correct
<awoods>acoburn1: ok, hit it.
<acoburn1>ok, I'll issue a PR after https://github.com/fcrepo4-labs/fcrepo-camel-toolbox/pull/16 is merged16:05
otherwise, there might be hell to pay with rebasing
<awoods>right
escowles: should I move the following ticket out of "in review" until you work out the errors? https://jira.duraspace.org/browse/FCREPO-148916:06
<escowles>awoods: yes, that makes sense
<awoods>done16:07
* dhlamb leaves16:10
* escowles leaves16:11
* acoburn1 leaves16:44
* acoburn joins
* github-ff joins16:56
[migration-utils] mikedurbin pushed 1 new commit to master: http://git.io/vfE91
migration-utils/master 1986787 Daniel Lamb: Added support for RELS-INT RDF migration.
* github-ff leaves
* github-ff joins16:57
[migration-utils] mikedurbin closed pull request #6: Migrating RELS-INT appropriately. (master...rels-int) http://git.io/vfCce
* github-ff leaves
* travis-ci joins16:58
fcrepo4-labs/migration-utils#15 (master - 1986787 : Daniel Lamb): The build passed.
Change view : https://github.com/fcrepo4-labs/migration-utils/compare/e811073be2ad...1986787bb168
Build details : http://travis-ci.org/fcrepo4-labs/migration-utils/builds/59787388
* travis-ci leaves
* github-ff joins16:59
[fcrepo-audit] mohideen opened pull request #4: Full URL form of PREMIS should be used for rdf:type (master...internal-audit) http://git.io/vfEQg
* github-ff leaves
* jgpawletko leaves17:01
* mikeAtUVa leaves17:02
* ajs6f leaves17:11
* acoburn leaves17:52
* whikloj leaves17:56
* github-ff joins17:59
[fcrepo-audit] acoburn opened pull request #5: added travis-ci configuration (master...travis-config) http://git.io/vfumA
* github-ff leaves
* github-ff joins18:03
[fcrepo-audit] awoods pushed 2 new commits to master: http://git.io/vfuOb
fcrepo-audit/master 08fe4f2 Aaron Coburn: added travis-ci configuration
fcrepo-audit/master e4f762d Andrew Woods: Merge pull request #5 from acoburn/travis-config...
* github-ff leaves
* travis-ci joins18:09
fcrepo4-labs/fcrepo-audit#3 (master - e4f762d : Andrew Woods): The build passed.
Change view : https://github.com/fcrepo4-labs/fcrepo-audit/compare/49730513c1c0...e4f762df4db3
Build details : http://travis-ci.org/fcrepo4-labs/fcrepo-audit/builds/59796234
* travis-ci leaves
* awoods leaves18:10
* dwilcox joins18:11
* ksclarke leaves18:17
* jcoyne leaves18:20
* awoods joins18:23
* awead leaves18:34
* jcoyne joins18:45
* github-ff joins19:23
[fcrepo4] escowles created default-identifier-translator (+1 new commit): http://git.io/vfuwI
fcrepo4/default-identifier-translator d9cc048 Esmé Cowles: Updating DefaultIdentifierTranslator to make it usable by audit service
* github-ff leaves
* github-ff joins19:24
[fcrepo-audit] escowles pushed 1 new commit to removeJCRleakage: http://git.io/vfuw0
fcrepo-audit/removeJCRleakage 2df53dd Esmé Cowles: Switching to DefaultIdentifierTranslator
* github-ff leaves
* github-ff joins19:25
[fcrepo4] escowles opened pull request #782: Updating DefaultIdentifierTranslator to make it usable by audit service (master...default-identifier-translator) http://git.io/vfuwQ
* github-ff leaves
* dwilcox leaves19:26
* MohamedAR leaves19:47
* jcoyne leaves20:14
* github-ff joins
[fcrepo-camel-toolbox] awoods closed pull request #15: Reuse AuditNamespaces and getAuditEventType from fcrepo-audit (master...master) http://git.io/vfCCa
* github-ff leaves
* travis-ci joins20:17
fcrepo4-labs/fcrepo-camel-toolbox#45 (master - 53d23d0 : Andrew Woods): The build passed.
Change view : https://github.com/fcrepo4-labs/fcrepo-camel-toolbox/compare/5ec6b93c8bc4...53d23d0ffdf1
Build details : http://travis-ci.org/fcrepo4-labs/fcrepo-camel-toolbox/builds/59809922
* travis-ci leaves
<f4jenkins>Project fcrepo-camel-toolbox build #47: UNSTABLE in 3 min 25 sec: http://jenkins.fcrepo.org/job/fcrepo-camel-toolbox/47/20:18
Mohamed Abdul Rasheed: Reuse AuditNamespaces and getAuditEventType from fcrepo-audit
* ksclarke joins20:27
* MohamedAR joins20:38
* ksclarke leaves20:53
* github-ff joins21:07
[fcrepo4] awoods opened pull request #783: Lessen leakage of JCR dependent code that extends beyond the kernel. (master...fcrepo-1487) http://git.io/vfuAQ
* github-ff leaves
* ksclarke joins21:09
* MohamedAR leaves21:38
* jcoyne joins22:42
* github-ff joins23:06
[fcrepo-audit] acoburn opened pull request #6: added test gear for fcrepo integration testing (master...fcrepo-1481) http://git.io/vfzZw
* github-ff leaves
* jcoyne leaves23:30

Generated by Sualtam