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

Using timezone: Eastern Standard Time
* dwilcox joins07:14
* mohamedar joins07:31
* awoods joins07:56
* dhlamb joins08:30
* osmandin joins09:23
* peichman joins09:47
* peichman1 joins09:59
* peichman leaves10:00
* mohamedar1 joins10:01
* mohamedar2 joins10:02
* mohamedar1 leaves
* mohamedar leaves10:05
* ksclarke joins10:17
* whikloj joins10:38
* acoburn joins10:44
* peichman1 leaves11:09
* mohamedar2 leaves
* mohamedar joins11:11
* peichman joins
* mohamedar1 joins11:13
* acoburn leaves11:14
* mohamedar leaves11:15
* ajs6f joins11:16
* bseeger joins11:19
<ajs6f>awoods: Of course acoburn can speak for himself re: throw a runtime exception or not for bad WebACl config, but there's a larger principle I want to take forward from there: without validation, it's easy to mung a repo _without knowing you did it until much later_. So what can we do? Well, one thing we can do is to err on the side of being loud when config is bad at runtime. No silently swallowing junk, no quiet unassertive log messages. If the semantics are ge11:26
awoods; And do it with loud, gross vomit noises.
<awoods>ajs6f: agreed... at least in the less graphic version of the principle.11:28
<ajs6f>awoods: Well, at least the repo should emit a huge, stinky burp. I mean, _a cost must be paid_.
<whikloj>ajs6f: I missed some of this conversation, but aren't you speaking _for_ consistency?
<ajs6f>whikloj: I am all for consistency, _when we have a clear, common, executable definition of what consistency is_. In the case of WebACL config, that is true. In the general case, HA.11:29
<whikloj>ajs6f: gotcha
<ajs6f>whikloj: Another example might be transform config.11:30
<whikloj>ajs6f: so as I recall part of the issue with validating the WebAC data is that we would have to create a new endpoint to have that data PUT/POST/PATCHed at. Because this would require the extra validation layer that the normal endpoint does not provide. Is there a better way to tie into the existing LDP, but add a validation layer?11:31
<ajs6f>We had (literally years ago) dreamed of self-hosting the basic persistence and structural config in the repo itself, but that seems like a bridge too far, now.
whikloj: Hm. From the POV of generality, what I would like to do is have a series of RdfStream subtypes that validate things, and some way to switch the P/P/P endpoints to use the different types of stream, on a map from URI to RdfStream type.11:33
<whikloj>ajs6f: So based on a...header (for example) you would attempt to map the incoming RDF against a schema of some sort?11:35
<ajs6f>whikloj: Well, let's stay away from loaded terms like "schema", but yeah that there would some kind of exposure via HTTP of a selection of stream types. The issue is that you would want to _enforce_ the choice of type for WebACL.11:49
<whikloj>ajs6f: Right, so once you had enabled WebAC on the repository this validation would not be optional11:50
<ajs6f>whikloj: Right, and that's a lot harder. It's one thing to provide some feature to _allow_ people to validate their crud. It's another to _force_ them to do it. It's the difference between adding API surface and changing workflows.
* mcritchlow joins11:58
<ajs6f>whikloj: I think what we're talking about here are new LDP interaction models. This is something we need to understand as an extension to LDP. There isn't a canonical way to do that, from what I know (although especially barmintor, escowles, and especially Rob Sanderson all understand LDP more deeply than do I). So we have to think this through. The question: if we subtype the LDP types (RDF Resource, NonRDF Resource, different Containers, etc.) can we subtype 12:00
* dwilcox leaves12:01
<whikloj>ajs6f: so (and I have very limited LDP understanding) would we be making the WebAC ACL and Authorization types become subtypes of the standard LDP types?
<ajs6f>whikloj: right.12:02
<whikloj>ajs6f: then our validation is based on the type of the resource... interesting
* dwilcox joins
* dwilcox leaves
<ajs6f>whikloj: one problem is that webacl is unaware of ldp, or i suppose they would have _used_ ldp types. e.g. instead of an acl resource via link, maybe they would have put things under the same acl inside the same indirect container, or something. But that's now how it is.12:07
<whikloj>ajs6f: well, lets be clear. WebAC is barely a recommendation. The implementation was how we chose to do it. So it could be changed.12:10
ajs6f: for instance the webac:Acl is a type of our creation.12:11
ajs6f: but the acl:Authorization is more problematic12:12
<ajs6f>whikloj: Maybe, then, our first step might be to step back and look at the initial impl for webacl. (I hate to say that after all the work...)12:18
<whikloj>ajs6f: I'm not so sure. I would say the first step is what you said above about this being a new interaction model. If we define that, then we can look to make WebAC work with it.12:19
<ajs6f>whikloj: that's more or less what I meant.12:20
<ajs6f>whikloj: Did the fcrepo group that did the impl have any contact with the WebACL group?
WebAC. Whatever.12:21
<whikloj>ajs6f: no, not that I am aware of
<ajs6f>whikloj: Clean slate. Okay, is there an ongoing group within fcrepo for WebAC, or once the sprints ended, was that it?
<whikloj>ajs6f: I'd say there are interested parties, but (of course) limited development resources. So with a working implementation we have stepped back.12:22
<ajs6f>whikloj: That, in a nutshell, is the history of Fedora 4.12:23
whikloj:awoods: This is a parallel development to Memento. We have a good candidate standard for some widely-desired functionality in the core API. We need to 1)12:24
whikloj:awoods: Make it work with LDP (as a part of LDP) and 2)
whikloj:awoods: impl that.
* bseeger leaves12:32
<whikloj>ajs6f: ok I have (against my better judegement) subscribed to the W3 Read-Write-Web mailing list. I see some discussion in their archives around LDP, so I think it is on their radar.12:51
<ajs6f>whikloj: Is that the group what produced WebAC?12:52
* bseeger joins
<whikloj>ajs6f: it is the suggested mailing list on the WebAccessControl page of the W3
<ajs6f>whikloj: Cool. Maybe we should ping Rob Sanderson. He's very connected into that scene.12:56
<whikloj>ajs6f: yeah, he might have an "in"13:05
* bseeger leaves
<ajs6f>whikloj: Okay, I'll send mail13:06
* peichman leaves13:18
* ajs6f leaves13:22
<rarian>I'm trying to debug a 3.8 install talking to an external ActiveMQ server; I'm seeing an openwire connection to our ActiveMQ, but all messages fail with a broken pipe/socket.13:43
Any pointers for where to dig into this one?
<whikloj>rarian: so you are consuming your Fedora JMS messages off of the internal ActiveMQ from an external ActiveMQ instance? Are both using a "queue" instead of "topic"?13:48
<rarian>whikloj: Instead of using the internal ActiveMQ, I've configured fedora to publish to an external ActiveMQ instance.13:50
Updates are being pushed to a queue, but access are just a topic in my configuration right now.13:51
<whikloj>that's fine most people don't consume access. But you don't see the JMS messages arriving at the external ActiveMQ?
<rarian>No, every message triggers multiple stracktraces in Fedora.13:52
<whikloj>What is the error message?13:53
oh sorry broken pipe/socket13:54
<rarian>Ultimately, yes.
<whikloj>Sounds like Fedora can't access the external ActiveMQ server
ports are specified correctly13:55
rarian: I've never done this, but people smarter than I have suggested keeping the internal ActiveMQ active queue active, but then set up a JMS consumer to read from the internal and write to the external.
whoa, lots of "active" in that sentence
<rarian>whikloj: That sounds like a good solution, any chance there's any documentation on how to do that?13:56
<whikloj>rarian: Not off the top of my head, it was acoburn that suggested. So I would say a very simple camel route would do it.
rarian: http://camel.apache.org/activemq.html13:57
<rarian>Alrighty, thanks for the tip.13:59
<rarian>I'm definitely looking forwarding to not having to deal with 3.8 anymore.14:05
* peichman joins
* peichman leaves14:07
* ajs6f joins14:10
<whikloj>rarian: not tested, but something I'd try something simple like this. https://gist.github.com/whikloj/4250de7ebbdfe6499ce1
<ajs6f>whikloj: Okay, from a clean clone of fcrepo-module-auth-webac, I get:
[ERROR] [ERROR] Some problems were encountered while processing the POMs:
[FATAL] Non-resolvable parent POM for org.fcrepo:fcrepo-module-auth-webac:[unknown-version]: Could not find artifact org.fcrepo:fcrepo:pom:4.5.1-SNAPSHOT and 'parent.relativePath' points at wrong local POM @ line 3, column 11
whikloj: Was something missed during the release process?14:11
<whikloj>ajs6f: good question
<ajs6f>whikloj: Shouldn't fcrepo-module-auth-webac depend on a released fcrepo, not a SNAPSHOT?14:12
<whikloj>ajs6f: So this is a clone from github? Wouldn't that always point to the current development env?14:13
* escowles leaves
<whikloj>ajs6f: Or you'd be developing against old Fedora code
* peichman joins
<whikloj>ajs6f: You probably just need to build the fcrepo4-4.5.1-SNAPSHOT first14:14
<ajs6f>whikloj: Only if the modeule in question is actually part of X should it depend on X-SNAPSHOT, to my mind. Otherwise you are coding against stuff that could change out from under you.
<whikloj>ajs6f: So then the auth modules would not be updated until after a new release of Fedora came out?14:15
ajs6f: but their could have been an issue and that darn ruebot is lying on a beach in mexico
<ajs6f>whikloj: It's true that building a SNAPSHOT fcrepo did let the module compile, but that shouldn't have to happen.
whikloj: No, the auth modules can update whenever they like. But they should always depend on release, not snapshot. Otherwise, they can randomly stop building because someone is tinkering with the core. (Yes, there are always going to be temprary exceptions, but _usually_.) I don't think it's any big deal. I wouldn't worry about it now, we can have a conv about on Thursday.14:17
<whikloj>ajs6f: Fair point
<ajs6f>whikloj: Managing dependencies is about managing dependency. — Fedo Raadmin14:18
<whikloj>ajs6f: it should not be pointing to fcrepo as its parent anyways. At the very least it should use the fcrepo-parent
<ajs6f>whikloj: That's a good point too
<whikloj>ajs6f: I think these modules are still tightly coupled to fcrepo so the benefit of sharing POM dependencies might be...colouring the decision14:19
* bseeger joins14:20
<ajs6f>whikloj: That's what BOMs are for.
* whikloj goes to google
whikloj: We even publish BOMs already:
I feel like there's some kind of joke about "dropping a BOM" available here, but I'm just not cool enough to make it.14:23
<whikloj>I'm sure you could pull it off.
ajs6f: so why does fcrepo4 have fcrepo-parent is its parent instead of fcrepo-bom?14:25
<ajs6f>whikloj: BOMs aren't for inheriting-from. You import them, instead. This gives you much more flexibility.14:26
<whikloj>ajs6f: ok...so why don't we have a simple POM for fcrepo4 that imports the fcrepo-bom to give us the libraries and versions. Or did a miss an important step in the docs?14:28
oh I see
So fcrepo-parent should actually import the BOM, then fcrepo4 would still have fcrepo-parent as its parent14:29
actually Maven suggests our top-level should be a pom artifact named bom with a sub-module of the parent pom with sub-modules as the rest of the projects. Clear as...14:34
<ajs6f>whikloj: Well, it's a spectrum. You get as sophisticated as you need to to get as much flexibility as you and your community need.14:35
* github-ff joins14:36
[fcrepo-module-auth-webac] ajs6f created FCREPO-1885 (+1 new commit): https://git.io/vgJnB
fcrepo-module-auth-webac/FCREPO-1885 91bedde ajs6f: FCREPO-1885: Removing Pair type in favor of specific type
* github-ff leaves
* github-ff joins14:37
[fcrepo-module-auth-webac] ajs6f opened pull request #53: FCREPO-1885: Removing Pair type in favor of specific type (master...FCREPO-1885) https://git.io/vgJnE
* github-ff leaves
<ajs6f>whikloj: ^^^ all yours
<whikloj>ajs6f: You are going to make me have to rebase my code aren't you :)
<ajs6f>whikloj: Rebasing your code is what tells you that other people are interested in your project. Be happy.14:38
* travis-ci joins14:41
fcrepo4/fcrepo-module-auth-webac#91 (FCREPO-1885 - 91bedde : ajs6f): The build passed.
Change view : https://github.com/fcrepo4/fcrepo-module-auth-webac/commit/91beddebd08e
Build details : https://travis-ci.org/fcrepo4/fcrepo-module-auth-webac/builds/106299824
* travis-ci leaves
* peichman1 joins14:59
* peichman leaves15:01
* ajs6f leaves15:15
* bseeger leaves15:44
* mcritchlow leaves16:05
* mcritchlow joins16:07
* dhlamb leaves16:08
* mohamedar joins
* mohamedar1 leaves16:10
* mohamedar leaves16:12
* mcritchlow leaves16:17
* peichman1 leaves16:23
* peichman joins16:28
* mcritchlow joins17:13
* mohamedar joins17:56
* whikloj leaves17:58
* peichman leaves17:59
* mcritchlow leaves18:02
* mcritchlow joins18:05
* awoods leaves18:47
* mohamedar leaves18:57
* mcritchlow leaves19:15
* mcritchlow joins19:39
* mcritchlow leaves19:43
* mcritchlow joins19:46
* dhlamb joins20:05
* mcritchlow leaves20:18
* mcritchlow joins21:27
* dhlamb leaves22:30

Generated by Sualtam