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

Using timezone: Eastern Standard Time
* escowles joins00:47
* escowles_ leaves00:49
* thomz joins02:36
* dwilcox joins07:54
* manez joins08:12
* dhlamb joins08:40
* esm_ joins08:41
* mikeAtUVa joins09:01
* ajs6f joins09:25
* esm_ leaves09:26
* bseeger joins09:27
* peichman joins09:34
<ajs6f>awoods: I'm bumping Harsha's tix to cirtical.09:39
critical
awoods: There may be nothing there, but if there is, it could be ugly.09:40
<awoods>ajs6f: ok... I think his assumption is that within a given version you should be seeing the specific version of children when the parent version was created.09:41
ajs6f: That is reasonable... just not what the current logic does.
<ajs6f>awoods: Yeah, what I mean is not that I think he really has uncovered a massive bug— I mean that he's a reasonably intelligent human being who is experiencing a serious cogniitve dissonance confronted by our product and docs. That's the critical part.09:42
awoods: We want to clarify that Fedora cannot access the Akashic records.
awoods: I expect that closing his tix will actually require work on the docs.09:43
<awoods>ajs6f: or we could change the impl to do what he is suggesting.09:44
<ajs6f>awoods: That seems vaguely horrifying. You/he seem to be suggesting that versioning a container versions everything inside it no matter what happens inside it and that every change that impinges on anything in that container (whether or not the impinged resource was actually explicitly altered) will forever be accessible. I don't think we can do that, but if we can, I don't think we should, and if we do, I would want to make it exquisitely 09:46
<awoods>ajs6f: I don't think that is what Harsha is suggesting... but it may be worth asking for such clarification in the ticket.09:50
* apb18 joins09:54
* apb18 leaves09:58
* FrozenOne joins10:07
* apb18 joins10:11
<ajs6f>apb18++ # Level up!10:33
<apb18>ajs6f: Thanks!10:34
<barmintor>I don't understand why fcr:versions would ever appear more than once in a resolveable URL10:35
<mikeAtUVa>me neither
<ajs6f>I _think_ he hand-constructed that URRI based on adding "elbows", instead of actually following links.10:36
<awoods>barmintor/mikeAtUVa: is what you would expect captured in the comment: https://jira.duraspace.org/browse/FCREPO-2117?focusedCommentId=51240&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-51240
<ruebot>apb18++
<barmintor>awoods: I would remove the parentheticals, they are confusing me
<awoods>barmintor: do you have another notation for specifying a specific version?10:37
<barmintor>awoods: whatever the relevant fcr:versions URL is
<awoods>barmintor: also, could you add an item to todays agenda relating to your modeshape/performance work? https://wiki.duraspace.org/display/FF/2016-08-11+-+Fedora+Tech+Meeting10:38
<mikeAtUVa>awoods: I don't actually know what I would expect... I'd be a little surprised if you can fully actually navigate through contained/versioned resources, and much more suprised if it's even moderately intuitive.
<awoods>mikeAtUVa :(
<barmintor>I don't think that's frownable! The versioned subtree doesn't contain those versions!10:39
<mikeAtUVa>awoods, I know... it's just *really* complicated.. on the bright side, I have fairly high confience that the version information is all there and if we came up with an intuitive way to present it, we'd be golden.
<awoods>mikeAtUVa: that is the challenge... coming up with an intuitive presentation/navigation.10:40
<ajs6f>awoods: Why is there no option to just comment on those value calims? That webpage demands you either approve or disapprove them. Not a useful system.
<awoods>dwilcox^^
<barmintor>awoods: the thing that is critical to note is that inner2/fcr:versions/V2 does not necessarily contain inner3/fcr:versions/V110:41
<ajs6f>dwilcox: I get that you're trying to extract some kind of ordering or notion of priority there, but it would be nice to be able to just say "I think these two things should be combined" or " I would like a to change the wording like so"
<barmintor>awoods: it should contain whatever the canonical content of inner3 was at the time the V2 was minted10:42
<awoods>barmintor: ..regardless of inner3's versioning?10:43
<barmintor>awoods: yes, because that versioning is independent10:44
awoods: what if inner3 had changed, but no version had been minted, and then you minted a version of inner2?
<awoods>barmintor: I get that.10:45
<barmintor>awoods: that's what I'm saying. there are no named versions further down the subtree. The version is frozen.
<ajs6f>barmintor: Is another way to say it; once you make a version of something, if a subsidiary resource of that thing changes, and you allow that change to appear in the versioin you made, then you wouldn't really have minted a version. ?10:47
<awoods>barmintor: on a related note, this seems to be effort that is very different from what we are moving towards with: http://fedora.info/spec/resource-versioning
<barmintor>awoods: it absolutely is, because the current versioning is 100% JCR
<awoods>barmintor: which raises the question of whether it is worth changing the current approach right before changing it again.10:48
<barmintor>awoods: I get why JCR does it this way, but I don't think it makes sense to anyone. That I think is worth a :(
<mikeAtUVa>in fairness to the implementation and its implementors, we used to like JCR before we discovered this whole LDP thing...10:49
<awoods>barmintor: can you save the tech agenda?
<barmintor>meh. I was one of them implementors too. It was just a thing called versioning that was at hand
b/c the sponsors couldn't actually say what they meant by versioning, either10:50
I bet awoods and ajs6f remember people lamenting about the lack of "whole object versioning" in 3.x as well
<ajs6f>Can they now? I suspect not.
<mikeAtUVa>the current problem of telling people what to do about versioning is tricky though... I'm tempted to say, don't use versioning yet... an indeed that's the course I'm taking...
<barmintor>ajs6f: no, I don't think so10:51
<ajs6f>barmintor: Yes, but I also remember caring. Time passes.
<barmintor>mikeAtUVa: or at least, understand what you're seeing
mikeAtUVa: this is where I think we're failing, we aren't explaining whhat the versions are
<ajs6f>I suspect that part of the problem here is that we want (and the API spec does) discuss versioning as a maniuplation of representations, but the JCR (and our impl) have to deal with a manipulation of resources. When does a change in a resource because visible in a given representation? When does it not?10:52
Versioning multiples the number of resources and the number of representions by the number of versions.10:53
<barmintor>ajs6f: this is why I'm saying that even if the current versioning presented they way they're asking it to, it wouldn't mean what they want it to
<ajs6f>We get confused sometimes mapping from a single resource to only a small number of representations. This is even harder.10:54
<barmintor>awoods: I added the line, I don't know how to do the fancy jira macro
<awoods>barmintor: just paste in the jira link... the macro will simply happen.10:55
<ajs6f>barmintor: This is why when I feel like nailing down people's desires for Fedora is like https://www.youtube.com/watch?v=oMsMGMtTJkM10:56
<dwilcox>ajs6f: The voting platform is not 100% ideal but we're basically treating the "Pros and Cons" as comments. So feel free to leave a neutral comment and it will be treated as such
ajs6f: Good Moderator doesn't exist anymore and I reviewed a few other options but I couldn't find anything better than this one
<ajs6f>dwilcox: okay— it's not like I've done any research on voting platforms.10:57
dwilcox: Is the intent there just to assemble some bullet points to keep in your pocket, or is there a specific dissemination to which you are working?10:58
* kat3_drx joins10:59
<ajs6f>See 
Error rendering macro 'jira' : java.lang.NullPointerException
Hi, everybody!11:01
all: Hi, Doctor Nick!
<awoods>https://wiki.duraspace.org/display/FF/2016-08-11+-+Fedora+Tech+Meeting
* acoburn joins11:02
* ruebot is here
* ajs6f is here.
<acoburn>*is here*
* escowles is here
* tjohnson joins
<dhlamb>have a conflicting appointment. can' make it today folks11:03
<ajs6f>So many lovely people!
<kat3_drx>full house today11:04
* barmintor is here
* ajs6f emits applause11:05
<escowles>apb18++
<tjohnson>👏
<barmintor>welcome aboard apb18
<ruebot>apb18++
<acoburn>apb18++
<barmintor>err, welcome *back* aboard
<ajs6f>Re-welcome, I should think.
<kat3_drx>apb18++
<dwilcox>apb18++
<apb18>ha, thanks!
<ajs6f>He knew what he was in for and he still did it. No one to blame but himself.
* jrgriffiniii joins
* ruebot snorts
* manez leaves11:06
<awoods>https://jira.duraspace.org/browse/FCREPO-209811:09
<escowles>maybe it's If-Match header was rejected?
<ajs6f>escowles—
And he really means "SHOULD"11:10
* thomz leaves
<barmintor>we also have wiki tags
<ajs6f>escowles: You might want to give a bbrief exaplanation of weak vs. strong
I suggested the hell out of that suggestion.11:11
<tjohnson>there's a long list of requirements for strong etags, here: https://tools.ietf.org/html/rfc7232#section-2.1
if a single bit changes in the payload, the etag must be different
<ajs6f>" A "strong validator" is representation metadata that changes value whenever a change occurs to the representation data that would be observable in the payload body of a 200 (OK) response to GET."11:12
<tjohnson>also, the strong etag must be unique across representations of the resource
unless they are bitwise equivalent
<ajs6f>I think we once talked about "semantically equivalent" in this context roughly meaning "these two graphs entail each other".11:13
<escowles>if anyone wants some light bedtime reading, here's the relevant HTTP spec (RFC 7232): https://tools.ietf.org/html/rfc7232
<ajs6f>escowles: I am putting down the Curious George for my son and trying that out this evening. I bet it works like a charm.11:14
<tjohnson>https://github.com/fcrepo4/fcrepo4/pull/1089#issuecomment-239187738
* manez joins11:15
<ajs6f>acoburn:escowles:barmintor:tjohnson: Did anyone ping Rob Sanderson on this? I'd be curious to hear any thoughts from him.11:16
<escowles>ajs6f: i don't think so — it would be a good idea to ask him
<ajs6f>escowles: That why I had it so late, when it won't do any good for this conv.11:17
<escowles>ajs6f: i'm not optimistic about resolving this issue on this call, so maybe there's hope :-)
<ajs6f>escowles: Your pessimistic optimism cheers me down.
<barmintor>ajs6f: caching11:18
escowles++ // it's a lot, IMO11:19
<tjohnson>there was discussion on this in the LDP WG in 2013 https://github.com/fcrepo4/fcrepo4/pull/1089#issuecomment-239187738
ooops, wrong link
<barmintor>escowles: it's the same thing given the speed with which Fedora can process updates
<tjohnson>this one: https://lists.w3.org/Archives/Public/public-ldp-wg/2013Feb/0035.html
<ajs6f>barmintor: The same thing as what?11:20
<barmintor>ajs6f: Not-Modified-Since being functionally equiv to ETag
<ajs6f>barmintor: What has that got to do with the speed of the impl?11:21
<escowles>ajs6f: barmintor: our timestamps are effectively unique identifiers of the state of the resource, b/c we can't update them too fast to make that not true
<barmintor>ajs6f: b/c the identity value of Last-Modified is only true if updates cannot happen sub the finest granularity of your timestamp
what escowles said11:22
<ajs6f>barmintor: escowles: Okay by me.
LDPNext?11:23
<tjohnson>I agree with escowles that we are already incompatible11:24
no LDP client is going to scrub the "W/"
<escowles>tjohnson: and i *really* don't want to encourage people to do that
<barmintor>tjohnson++ // they might just recirculate whatever the etag was, but they won't yank the weak indicator11:25
<ajs6f>My understanding of the weak-strong distinction has to do with how people live on the streets!
Only the strong survive!
They refer to the response body explicitly.11:27
Why does barmintor always sound like Max Headroom?
Yeah, it's quite a blast from the past.
<escowles>ajs6f: don't make him self-conscious
<tjohnson>ajs6f++
<barmintor>there's no way to know that you got the response for which that etag
<ajs6f>It's true that barmintor is terribly shy.11:28
<barmintor>was a strong validator of representation
in the same format as the data you are sneding
so I don;t think you can make the claim
that you are able to drop the w/ in this way
because it is 2 stateless requests11:29
one GET, one PUT, up to 2 Content-Type values
yes
thanks from the other side of the veil ajs6f and tjohnson
<escowles>obligatory: https://www.ietf.org/rfc/rfc114911:30
<ajs6f>Oh, no! barmintor is a spirit at a seance!
<ruebot>what's the duraspace shipping budget look like dwilcox?
<tjohnson>barmintor: let's hold an ETag seance11:32
<ajs6f>Can you transmit HTTP messages via ectoplasm?11:33
<apb18>just so I understand - If-Match will always fail, so LDP clients need to not use If-Match
<escowles>apb18: correct
<barmintor>apb18: not unless they got a strong ETag
ruebot: can you tell us what CLAW does11:34
<escowles>ruby-ldp shouldn't use the weak etag, it should fall back on if-unmodified-since
<barmintor>escowles: yes, and that will be patched quickly
<ajs6f>apb18:barmintor: giving strong etags just seems beyond impossible for RDF.
* dchandekstark joins
<barmintor>ajs6f: with conneg on format, yes
<ruebot>barmintor: we don't have an LDP client11:35
<ajs6f>CLAW does what it always does: arm wrestle like champions! http://www.clawusa.org/
<escowles>i think you could serialize the RDF and use checksums of the content, to have strong ETags on RDF content — but that would obviously be a pain
<apb18>ajs6f: Right - so the natural conclusion (if we cannot support strong etags) is to fail an If-Match always
<barmintor>ruebot: but do you use request validation on PUT
* ruebot looks at chullo source11:36
<ajs6f>apb18: To RDF resources. Binaries are a whole 'nuther story.
Bitstreams, we can actually give strong ETags.
<apb18>ajs6f: Ah, right
<barmintor>acoburn: FWIW I think the real problem here is on ruby-ldp side, the uses of which just stumbled on a FCR4 loophole
<ajs6f>escowles: That would be a performance nightmare.
escowles: And a memory bomb.11:37
escowles: And generally just icky.
<escowles>ajs6f: yep, definitely icky
<ruebot>barmintor
<barmintor>ruebot
<ruebot>barmintor: not looking like it, but i'll verify with dhlamb when he gets back from the dentist.11:38
<barmintor>ruebot++
<ruebot>barmintor: https://github.com/Islandora-CLAW/chullo/blob/ba0911a4f11bd79c7b08dc67a2579871d891026c/src/FedoraApi.php#L164-L196
<barmintor>tjohnson++ // I think that is exactly right
<ruebot>barmintor: if you really want to look at BEAUTIFUL php
<ajs6f>ruebot: are you saying dhlamb missed this important converstation for something as unimportant as his teeth?!?!
tjohnson++11:39
<escowles>tjohnson++ sounds good to me
<ruebot>ajs6f: dhlamb = Mr. Perfect Teeth
<barmintor>we're not even getting into PATCH
<ajs6f>ruebot: That is not really a great wrestling name.
<acoburn>barmintor: or DELETE
* dchandekstark leaves11:40
<ajs6f>Misbehavior is actually not a terrible wrestling name.
Or for a lady arm wrestler, "Miss Behavior".
<barmintor>it's a rollerderby classic
<ajs6f>barmintor++11:41
<barmintor>ajs6f: I think we can leave the FCR code alone
<ajs6f>YAYAYAYYAYY!
<barmintor>FOR NOW
<ajs6f>No, FOREVER.
escowles++11:42
* github-ff joins
[fcrepo4] escowles closed pull request #1089: Refuse updates to containers that include If-Match headers (4.6.0-RC...containers-never-match-RC) https://git.io/v6Cw7
* github-ff leaves
<barmintor>cur-rent sta-tus *stadium clap*
<ajs6f>STATUS QUO is a good name for a bad metal band. But not a good metal band.
That sounds powerful.
Kind of a low-fi, Pavementy thing.11:43
<tjohnson>escowles: the serialize & checksum only works if you can guarantee order of statements
and depending on serialization, guarantee things like CURIE prefixes, statement embedding, etc... will be identical11:44
<escowles>tjohnson: right — you'd have to have them already serialized to use that order that you happened to get
<tjohnson>escowles: but if I send PUT with if-match, it's not going to match if the serialization changes when I check11:45
<ajs6f>tjohnson: Given the nature of RDF toolkits, it is almost impossible to guarantee against that change.
<tjohnson>i know it
<escowles>so you'd need to serialize after each update, and then use that serialization as the canonical form11:46
<ajs6f>escowles:tjohnson: I think these are the same deliberations through which the LP ground must have gone.
<tjohnson>yeah. and probably cache it
<ajs6f>group
s/LP/LDP11:47
<tjohnson>exactly
<ajs6f>esclowles:tjohnson: You could imagine some ultra-light LDP impl that just reads and writes NTRIPLES or something from disk. No SPARQL Update.11:48
<barmintor>awoods: the other part is just ushering the id converter PR in
awoods: which ajs6f and acoburn are looking at
<ajs6f>I've looked at it, and I'm basically okay with it.
<escowles>tjohnson: you could always support SPARQL update by parsing the stored RDF into a model, applying the update, and then serializing back to disk
(which is gross and not something we would want to require, but i do think it's possible)11:49
<tjohnson>ajs6f: yeah; though it would minimally require a .ttl and .jsonld version of the on-disk file :)
<ajs6f>escowles: This is all feasible. It sure as hell is not what we are going to do in the current MODE impl.
<barmintor>acoburn: that would be wonderful, too, but 2 caveats:
1) the path and the URI are not a perfect correspondence
<ajs6f>tjohnson: Right, right. Anyway, you get the idea; deal directly in bits.
<barmintor>2) the node lookup for the subject is not th issue, it's the lookups of the N child nodes11:50
"child", really "referenced" nodes
ajs6f: that's right
* dchandekstark joins11:51
<barmintor>ajs6f: yes, that's also right
<ajs6f>barmintor: STOP AGREEING WITH ME.
<barmintor>awoods: I don't think so
awoods: :(11:52
<ajs6f>barmintor has the Voice of Thunder.
<ruebot>https://wiki.duraspace.org/display/FF/Design+-+Import+-+Export11:53
<ajs6f>ruebot: there's your wrstling name: The Shepherd.11:54
ruebot: You could actually enter the ring with a sheep and use your crook to hit your oppnents.
<ruebot>ajs6f: that lamb would be Danny Lamb, right????
<ajs6f>ruebot+++++
I saw them as in order of which got the most votees.11:56
<mikeAtUVa>dwilcox: are they meant to be aspirational, or descriptive?11:57
<ruebot>it says 7 days left11:59
<ajs6f>Whether or not you are interested.12:01
<barmintor>thx awoods
* acoburn leaves
<ajs6f>kat3_drx++
<kat3_drx>I'll post my hopefully semi-coherent notes this afternoon12:02
<awoods>kat3_drx: thanks!
<ajs6f>If your notes are too well-organized, they will give me people a false impression of what the project is really like.
<kat3_drx>tjohnson if you have a link to rfc7232 info, please feel free to add it
<dwilcox>ajs6f: They are in order of when the statements were added, with newer statements on the bottom. I didn't want to put them in order of most votes as this would likely bias further voting towards the most popular statements
<tjohnson>will do
<kat3_drx>ajs6f: I'll be selective :)
tjohnson thanks!12:03
<ajs6f>dwilcox: Weird. I must have hit something to do that.
* kat3_drx leaves
* github-ff joins12:04
[fcrepo4] awoods deleted containers-never-match-RC at 58c7293: https://git.io/v6BRz
* github-ff leaves
* github-ff joins
[fcrepo4] awoods deleted containers-never-match at 2d719df: https://git.io/v6BRa
* github-ff leaves
<ajs6f>afk bbl12:07
* ajs6f leaves
* kat3_drx joins12:15
* bseeger leaves12:16
* kat3_drx leaves
<f4jenkins>Project fcrepo-module-auth-rbacl build #1085: UNSTABLE in 2 min 43 sec: http://jenkins.fcrepo.org/job/fcrepo-module-auth-rbacl/1085/12:18
* chadmills joins12:27
<f4jenkins>Yippee, build fixed!12:28
Project fcrepo-module-auth-rbacl build #1086: FIXED in 2 min 50 sec: http://jenkins.fcrepo.org/job/fcrepo-module-auth-rbacl/1086/
* manez leaves12:32
* manez joins12:36
* bseeger joins12:44
* dwilcox leaves13:01
* github-ff joins13:09
[fcrepo-java-client] yinlinchen opened pull request #16: Add (master...FCREPO-2031) https://git.io/v6BoG
* github-ff leaves
* dwilcox joins13:11
* esm_ joins13:18
* kat3_drx joins13:26
* dchandekstark leaves13:28
* dchandekstark joins13:29
* kat3_drx leaves13:39
<ruebot>dhlamb: are you back?13:42
<dhlamb>ruebot: yes13:43
<ruebot>dhlamb: do we use request validation on PUT? I looked, and I don't think we do, but wanted to double-check.13:44
dhlamb: this has to do with Etags agenda item on today's call
<dhlamb>ruebot: not sure what you mean by request validation. but we expose the if-match and if-unmodified-since headers13:47
ruebot: we don't do any other sort of validation13:48
ruebot: meaning we don't check if rdf is malformed, etc...13:49
<ruebot>^^ barmintor13:50
dhlamb: more context in the log from earlier today if that helps.
<dhlamb>ruebot: yes, we pass along checksums as well, tho i believe that's now deprecated?13:52
<ruebot>dhlamb: deprecated as a query, but it's in the headers now.13:53
<dhlamb>ruebot: k, we'll have to change that13:54
ruebot: so If-Match fails on PUTs for everyone? or just the ruby ldp client?
ruebot: I manually tested all that stuff ages ago and remember it working, but it's been at least a year13:55
<ruebot>dhlamb: yeah, a lot has changed :-)
* bseeger leaves13:58
* mikeAtUVa leaves13:59
* esm_ leaves14:15
* dchandekstark leaves14:18
* escowles leaves14:19
* escowles joins
* dchandekstark joins14:21
* FrozenOne leaves14:23
* dchandekstark leaves14:24
* dchandekstark joins
* dchandekstark leaves
* dchandekstark joins14:27
* dchandekstark leaves14:32
* coblej joins14:42
* ajs6f joins14:48
* peichman leaves
* acoburn joins15:05
* dchandekstark joins15:15
<ruebot>ajs6f: all good with the vagrant tests.15:25
<ajs6f>ruebott++ # thanks!
* manez leaves16:08
* github-ff joins
[fcrepo-camel-toolbox] awoods pushed 1 new commit to master: https://git.io/v6RTa
fcrepo-camel-toolbox/master 3a6cc7f Aaron Coburn: Reimplement LDPath transforms as an OSGi service (#103)...
* github-ff leaves
* dhlamb leaves16:09
* travis-ci joins16:21
fcrepo4-exts/fcrepo-camel-toolbox#269 (master - 3a6cc7f : Aaron Coburn): The build was broken.
Change view : https://github.com/fcrepo4-exts/fcrepo-camel-toolbox/compare/a2730173af2c...3a6cc7f6b1ca
Build details : https://travis-ci.org/fcrepo4-exts/fcrepo-camel-toolbox/builds/151622542
* travis-ci leaves
<f4jenkins>Project fcrepo-camel-tests build #39: UNSTABLE in 2 min 31 sec: http://jenkins.fcrepo.org/job/fcrepo-camel-tests/39/16:22
* dwilcox leaves16:34
* barmintor leaves16:35
* mjgiarlo leaves16:36
<f4jenkins>Yippee, build fixed!16:38
Project fcrepo-camel-tests build #40: FIXED in 2 min 5 sec: http://jenkins.fcrepo.org/job/fcrepo-camel-tests/40/
* dwilcox joins16:46
<ajs6f>acoburn:awoods: Did you guys just merge a new backend into fcrepo-transofmr, or am I confused with all the PRs floatin around?16:48
<acoburn>ajs6f: it went into camel-toolbox
<awoods>ajs6f: The only merge that has happened is: https://github.com/fcrepo4-exts/fcrepo-camel-toolbox/commit/3a6cc7f6b1ca56d75e0248a3e9a72f81f2319cb3
<ajs6f>awoods:acoburn: Okay, cool. So we're still waiting on the new backend stuff. It would be nice to advertise that in conjunction with 4.6.016:50
<awoods>aj6f: the above merge is the new backend16:51
<acoburn>ajs6f: that will probably all be released much sooner (next week?), but yes, that will be part of the release notes
* escowles_ joins
<awoods>acoburn: that is interesting that the toolbox would be a part of the core release notes...16:52
* travis-ci joins
fcrepo4-exts/fcrepo-camel-toolbox#269 (master - 3a6cc7f : Aaron Coburn): The build was broken.
Change view : https://github.com/fcrepo4-exts/fcrepo-camel-toolbox/compare/a2730173af2c...3a6cc7f6b1ca
Build details : https://travis-ci.org/fcrepo4-exts/fcrepo-camel-toolbox/builds/151622542
* travis-ci leaves
<acoburn>awoods: that's not what I had in mind
awoods: I assume it's release schedule is entirely independent16:53
<awoods>acoburn: exactly
<acoburn>s/it's/its
<ajs6f>acoburn:awoods: No, not part of the core release notes. Just part of the same new cycle. Get people to notice that while 4.6.0 isn't an amazing step beyond 4.5.1, there are good things going on.
<awoods>acoburn: I misunderstood your comment: "that will probably all be released much sooner (next week?), but yes, that will be part of the release notes"
* dwilcox leaves
<ajs6f>s/new/news
<acoburn>awoods: I would like to release fcrepo-camel-toolbox next week
<awoods>acoburn++16:54
<acoburn>awoods: that has nothing to do with the current 4.6.0 release
<awoods>right
<acoburn>awoods: I would note, however, that this release of the camel-toolbox will be more of a bridge release — it won't be compatible with the 4.6.0 release of Fedora
* escowles leaves16:55
<acoburn>awoods: once this release goes out, I will make the changes related to the new Fedora version
<ajs6f>acoburn: is that because of the new messaging format?16:57
<acoburn>ajs6f: yes
<ajs6f>acoburn: So, release once with the new ldpath goodness and old messaging, then release again with the new messaging?
<acoburn>ajs6f: yes, the logic is that there are people out there using Fedora systems <= 4.5.x who are also using Camel (e.g. UMD)16:58
they have been waiting months for this release
…of fcrepo-camel-toolbox
<ajs6f>acoburn: Okay, let's just try and coordinate communications to get maximum bang and minimum confusion. the new ldpath goodness is awesome.16:59
<acoburn>ajs6f: will do
* dchandekstark leaves
<awoods>acoburn: There is still work to be done to enable fcrepo-indexing-solr to use the new transform service, no?17:00
<acoburn>awoods: there's that, too
awoods: but that's not so urgent, since fcrepo 4.6.0 will still contain fcrepo-transform
<awoods>true
<ajs6f>acoburn: if the default config is to cache into some disk store, what is that store? some kind of Sesame rdf db?17:03
<acoburn>ajs6f: yes, it's a disk-based sesame repo17:04
ajs6f: I don't actually know a lot about it — other than the fact that it is the simplest of the backends and easiest to configure
ajs6f: I've looked at the format of the data, and it all makes sense, but that's all the poking around I've done17:05
ajs6f: i.e. it keeps track of the URIs it dereferences and the time it last checked the remote URL
ajs6f: along with a serialization of all the triples that correspond to that URI; the triples are stored in a deeply nested directory structure17:06
ajs6f: I assume there's some sort of hashing function that maps the URI to a filesystem path
ajs6f: but that's just an assumption
* coblej leaves17:07
<ajs6f>acoburn: Okay, that all sounds pretty cool.
Just curious
<acoburn>ajs6f: there is also an ISPN (in-memory) backend, but I was sorta trying to avoid ISPN, and a JDBC-based backend (but that requires setting up a DB and more configuration17:08
<ajs6f>acoburn: I LUV ISPN.17:09
acoburn: Actually, one thing that could be interesting is JDBC taping an in-memory Apache Derby db.17:10
tapping
acoburn: That would be fast and pure-memory.
<acoburn>ajs6f: what would be _really_ nice would be to use pax-jdbc, but Marmotta and OSGi don't play nicely
<ajs6f>acoburn: I don't know what pax-jdbc is… something that lets you swap in dbs and OSGI services or something like that?17:11
<acoburn>ajs6f: yes, your DB connection is just an OSGi service
ajs6f: it's really quite nice
<ajs6f>acoburn: My DB connection is a big scary guy who hangs out on the street corner downtown.
acoburn: No, wait, that's my other connection.17:12
afk for the evening
* ajs6f leaves
* acoburn leaves17:17
* mjgiarlo joins
* dwilcox joins17:50
* dwilcox leaves17:51
* apb18 leaves18:34
* jrgriffiniii leaves18:38
* apb18 joins18:42
* apb18 leaves18:46
* apb18 joins19:45
* travis-ci joins19:58
fcrepo4-exts/fcrepo-camel-toolbox#269 (master - 3a6cc7f : Aaron Coburn): The build passed.
Change view : https://github.com/fcrepo4-exts/fcrepo-camel-toolbox/compare/a2730173af2c...3a6cc7f6b1ca
Build details : https://travis-ci.org/fcrepo4-exts/fcrepo-camel-toolbox/builds/151622542
* travis-ci leaves
* apb18 leaves20:02
* github-ff joins20:06
[fcrepo-camel-toolbox] awoods pushed 1 new commit to master: https://git.io/v6R6T
fcrepo-camel-toolbox/master 7e890f4 Aaron Coburn: Consolidate configuration of fcrepo-camel by wrapping it as an OSGi service (#101)...
* github-ff leaves
* github-ff joins20:07
[fcrepo-camel-tests] awoods pushed 2 new commits to master: https://git.io/v6R6t
fcrepo-camel-tests/master 06c909b Aaron Coburn: Consolidate configuration of fcrepo-camel by wrapping it as an OSGi service...
fcrepo-camel-tests/master ad56953 Andrew Woods: Merge pull request #8 from acoburn/fcrepo-2088...
* github-ff leaves
* travis-ci joins20:17
fcrepo4-exts/fcrepo-camel-toolbox#271 (master - 7e890f4 : Aaron Coburn): The build was broken.
Change view : https://github.com/fcrepo4-exts/fcrepo-camel-toolbox/compare/3a6cc7f6b1ca...7e890f487203
Build details : https://travis-ci.org/fcrepo4-exts/fcrepo-camel-toolbox/builds/151678535
* travis-ci leaves
<f4jenkins>Project fcrepo-camel-toolbox build #354: UNSTABLE in 12 min: http://jenkins.fcrepo.org/job/fcrepo-camel-toolbox/354/20:19
awoods: Consolidate configuration of fcrepo-camel by wrapping it as an OSGi service (#101)
* jrgriffiniii joins20:32
* travis-ci joins20:44
fcrepo4-exts/fcrepo-camel-toolbox#271 (master - 7e890f4 : Aaron Coburn): The build was broken.
Change view : https://github.com/fcrepo4-exts/fcrepo-camel-toolbox/compare/3a6cc7f6b1ca...7e890f487203
Build details : https://travis-ci.org/fcrepo4-exts/fcrepo-camel-toolbox/builds/151678535
* travis-ci leaves
* mjgiarlo leaves20:45
* dchandekstark joins20:50
* github-ff joins21:04
[fcrepo-camel-toolbox] acoburn opened pull request #104: Address transient build errors on travis (master...transient_build_errors) https://git.io/v6RMm
* github-ff leaves
* peichman joins21:10
* peichman leaves21:12
* travis-ci joins22:08
fcrepo4-exts/fcrepo-camel-tests#16 (master - ad56953 : Andrew Woods): The build has errored.
Change view : https://github.com/fcrepo4-exts/fcrepo-camel-tests/compare/0ceece2004b8...ad56953b4de2
Build details : https://travis-ci.org/fcrepo4-exts/fcrepo-camel-tests/builds/151678640
* travis-ci leaves
* dhlamb joins22:17
* dchandekstark leaves23:24
* tjohnson leaves23:37
* esm_ joins23:51
* dchandekstark joins00:24
* dchandekstark leaves00:30
* esm_ leaves01:10

Generated by Sualtam