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

Using timezone: Eastern Standard Time
* dhlamb joins08:40
* osmandin joins08:46
* jrgriffiniii joins09:08
* jrgriffiniii leaves09:09
* jrgriffiniii joins
* jrgriffiniii leaves09:14
* acoburn joins09:34
* ksclarke joins
* esm_ joins09:36
* dwilcox joins
<awoods>All: There is noise on the projecthydra channel about needing a 4.3.1 release ASAP...09:48
<acoburn>awoods: define ASAP
<awoods>All: we could shoot for the week of Sep 28th, or Oct 12
<acoburn>awoods: that seems reasonable09:49
<awoods>acoburn: 4.3.1 has a couple of bug fixes
acoburn: jcoyne has those bugs in production installs... and also wants updates for HC3 demos
<acoburn>awoods: for H3 demos, he can use a snapshot version09:50
awoods: for the OGG bug, couldn't he just drop a jar into the classpath of the running server?09:51
awoods: I mean wasn't that issue just about a certain dependency on tika (or something) that was being excluded?
<awoods>acoburn: yes, yes, and yes.09:54
<acoburn>awoods: so is there any rush on getting a release out? (I don't like the idea of rushing a release)09:55
<awoods>acoburn: nor I... see discussion in projecthydra09:56
* barmintor joins10:09
morning awoods
<awoods>barmintor: howdy10:10
barmintor: I believe we are meeting @10:30 on the hangout.10:11
<barmintor>awoods: yes, indeed
<awoods>dhlamb: nice recipes: https://github.com/daniel-dgi/fcrepo-camel-workshop
* github-ff joins10:14
[fcrepo4] awoods closed pull request #766: adding fixity events II (master...escfixity) http://git.io/veMPT
* github-ff leaves
* ajs6f joins10:20
<acoburn>dhlamb++10:25
<dhlamb>thx guys. still needs work. but for a workshop, these simple xml files should help people learn without getting bogged down in maven and configuration10:27
<acoburn>dhlamb: will you just have everyone copy them to $KARAF/deploy?10:28
<dhlamb>acoburn: that's the plan
<acoburn>dhlamb: nice
<dhlamb>acoburn: we'll see how that goes. if there's folks in the audience that aren't comfortable cp'ing something over, i might have issues10:29
<ajs6f>awoods: So far, what I've seen of people using transactions is actually people doing batch ingest.
<awoods>ajs6f: or incremental updates... needing all or none
<ajs6f>awoods: That's also a batch, if you consider a batch as occurring all or none.10:30
* acoburn leaves
<awoods>ajs6f: true
<dhlamb>ajs6f: awoods: finally getting around to using them while constructing pcdm objects, too. so we don't half build the direct and indirect containers.
<ajs6f>awoods: I think we need cwilper's Semantic Packages more than transactions.
https://tools.ietf.org/html/draft-wilper-semantic-content-pkgs-0010:31
awoods: That would need some updating, but in a more modern form it's a ready-to-go batch format.10:32
<awoods>on a call
<ajs6f>NNONONNONONONONON!!!!!!!!!!10:33
* dwilcox leaves10:40
* dwilcox joins10:47
<terrellt>ajs6f: SCP looks interesting.11:49
<ajs6f>terrellt: Yep. Useful, too. We never did anything with it, but if Chris had continued as tech lead, I suspect we might have cashed FOXML out in favor of something like SCP.11:51
* osmandin leaves11:55
* dhlamb leaves12:20
* dhlamb joins12:32
* jgpawletko joins12:41
* acoburn joins13:59
* dwilcox leaves15:20
<ajs6f>dhlamb: You could do that with a single transactional batch, no?15:50
<dhlamb>ajs6f: yep, building up more complicated PCDM objects within a transaction is precisely what we're doing15:51
<ajs6f>dhlamb: But are you doing it with back-and-forth, or do you actually know in advance what you what to see when you are done?15:52
<dhlamb>ajs6f: ? we know what they should look like. i don't stop to check it at any time until after i've committed the transaction.15:53
ajs6f: right now all i've got going is building collections and their indirect container. pcdm objects are the same but wih an extra direct container for files. i hope to have examples to show the F4 interest group that's meeting next week in islandora-land15:54
<ajs6f>dhlamb: Exactly. So yeah, that's a great example of _using_ but not _needing_ transactions.
dhlamb: You could, in theory, build a big message once and send it once, right?15:55
<dhlamb>ajs6f: oh sure, you don't _need_ them, but it's crazy not to use them if they're available
ajs6f: i can create batch messages and send them as a single message?
<ajs6f>dhlamb: Sure, sure, I'm not saying you are doing anything wrong.
<dhlamb>ajs6f: since when? totally gonna do that, too
<ajs6f>dhlamb: No, you can't, and my point is that if you _could_, you wouldn't need transactions.15:56
dhlamb: You are using transactions to "stand in" for the ability to batch transactionally.
<dhlamb>ajs6f: oh, yeah. you could dance around transactions that way. sometimes it would be nice to still have them in case you depend on something in another system getting created alongside resources in fedora. that way you can roll back the fedora stuff in case someting goes wrong in the other system15:57
ajs6f: but if you're clever, you could work it out without tx's
ajs6f: but for the record, i like transactions
<ajs6f>dhlamb: Right, but that's just not the use case we've ever been presented. It's all beeb variations on your stateduse case.
dhlamb: I have nothing against transactions. {grin} But they are hard (maybe impossible) to do correctly in REST.15:58
dhlamb: If we could be confident of meeting the use cases by other means, I would rather do that.
<dhlamb>ajs6f: you'd cringe if you saw what i'm doing. i have a rest api that does stuff like POST to /islandora/collection?tx=blah blah blah15:59
ajs6f: i know that's not RESTful, but I don't particuarly care. i think using query strings for optional parameters is useful
<ajs6f>dhlamb: You get the job done. That's the first thing.
<acoburn>ajs6f/dhlamb: do either of you have thoughts on this ticket: https://jira.duraspace.org/browse/FCREPO-1741 (it's about moving tx values into headers)16:00
<ajs6f>dhlamb: Someone will _eventually_ be unhappy you did that, but that may not be you. {grin}
<dhlamb>ajs6f: precisely. and if they want to change it, it's open source and i wouldn't stop them. as long sa it doesn't make you want to rip your hair out
manipulating the tx in the fedora uri is tricky enough sometimes
<ajs6f>dhlamb: Right. They can rip _their_ hair out. Just not yours.
<acoburn>ajs6f: I'm clearly way behind you (you've already added comments to the ticket)16:01
<dhlamb>ajs6f: i like the way you think :D
<ajs6f>acoburn: That's what started this conversation.
<acoburn>ajs6f: cool, just wanted to make sure
<ajs6f>acoburn: I am constantly creeping up behind you. In the nicest way, of course.16:02
<acoburn>ajs6f: of course
<dhlamb>acoburn: i'm don't lean too far one way or the other. i try not to get into 'what is more RESTful', etc... type debates. as long as tx's work, i'm cool. personally i'd prefer headers, but i understand the criticism16:03
acoburn: i understand jcoyne's point, too. i ran into this when bubbling tx's up through the rest api for PCDM objects i'm working through in my spare time16:05
acoburn: it is a bit odd that the uri changes once the transaction is committed, despite the fact that it is explicit
acoburn: but to be honest, a few lines of gross string manipulation took care of it. which i have to say, i find myself doing more and more of when working with dereferencable URI's16:06
acoburn: not a complaint, just more of a something i've noticed
has my tirade been non-committal enough, lol?16:07
<acoburn>dhlamb++
* dhlamb leaves16:11
* jgpawletko leaves16:12
* acoburn leaves16:42
* ajs6f leaves16:43
* esm_ leaves16:48
* jgpawletko joins17:07
* jgpawletko leaves17:32
* barmintor leaves17:54
* dwilcox joins
* dwilcox leaves18:09
* the_mgt_ joins19:24
* the_mgt leaves19:27
* dhlamb joins21:56
* dhlamb leaves23:36