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

Using timezone: Eastern Standard Time
* dwilcox joins08:13
* github-ff joins08:18
[fcrepo4] escowles pushed 1 new commit to external-content-redirect: http://git.io/KvUtqQ
fcrepo4/external-content-redirect 0524125 Esmé Cowles: Updating IT to use federated datastream source for external content
* github-ff leaves
<pivotal-bot__>Esme Cowles started "Seamless external content" https://www.pivotaltracker.com/story/show/7462775008:19
Esme Cowles added comment: "I've updated the PR to use a federated datastream for the external content: https://github.com/fcrepo4/fcrepo4�" https://www.pivotaltracker.com/story/show/7462775008:20
Esme Cowles finished "Seamless external content" https://www.pivotaltracker.com/story/show/74627750
* travis-ci joins08:29
[travis-ci] fcrepo4/fcrepo4#2329 (external-content-redirect - 0524125 : Esmé Cowles): The build passed.
[travis-ci] Change view : https://github.com/fcrepo4/fcrepo4/compare/a4553ff81220...05241259e0cd
[travis-ci] Build details : http://travis-ci.org/fcrepo4/fcrepo4/builds/35112662
* travis-ci leaves
<f4jenkins>Yippee, build fixed!08:32
Project fcrepo4 build #2117: FIXED in 14 min: http://jenkins.fcrepo.org/job/fcrepo4/2117/
* mohamed joins08:33
* awead joins08:35
* dwilcox leaves09:11
* dwilcox joins09:15
* whikloj joins09:19
* jcoyne joins09:25
<f4jenkins>Project fcrepo-message-consumer build #639: ABORTED in 16 hr: http://jenkins.fcrepo.org/job/fcrepo-message-consumer/639/09:30
* tecoripa joins09:32
* tecoripa leaves
<f4jenkins>Project fcrepo-message-consumer build #640: SUCCESS in 5 min 13 sec: http://jenkins.fcrepo.org/job/fcrepo-message-consumer/640/09:35
* ajs6f joins09:47
* github-ff joins09:53
[fcrepo4] ajs6f opened pull request #466: Nonfunctional code cleanup (master...CodeCleanup4Eva) http://git.io/lWK7Rg
* github-ff leaves
<ajs6f>awoods: That PR needs rebasing.09:56
I'll do it later this morning.
* github-ff joins
[fcrepo4] awoods pushed 1 new commit to master: http://git.io/1AGiRA
fcrepo4/master 11ab17c Esmé Cowles: Redirect to external content on GET of fcr:content...
* github-ff leaves
* github-ff joins09:57
[fcrepo4] awoods closed pull request #464: Redirecting to external content on GET of fcr:content (master...external-content-redirect) http://git.io/R6V-4g
* github-ff leaves
<pivotal-bot__>Andrew Woods added comment: "Resolved with: https://github.com/fcrepo4/fcrepo4/commit/11ab17c129aea33f3c87871338afa9061ab87055" https://www.pivotaltracker.com/story/show/74627750
Andrew Woods added comment: "@stefanoc, are you in a position to verify this? It has been committed to the master branch of fcrepo." https://www.pivotaltracker.com/story/show/74627750
Andrew Woods delivered "Seamless external content" https://www.pivotaltracker.com/story/show/74627750
<awoods>ajs6f: I will wait until you "Finish" the ticket: https://www.pivotaltracker.com/s/projects/684825/stories/7867187009:59
<pivotal-bot__>A. "Banjaxel" Soroka added comment: "https://github.com/fcrepo4/fcrepo4/pull/466" https://www.pivotaltracker.com/story/show/7867187010:02
<f4jenkins>Project fcrepo4 build #2118: UNSTABLE in 10 min: http://jenkins.fcrepo.org/job/fcrepo4/2118/10:07
awoods: Redirect to external content on GET of fcr:content
* travis-ci joins10:08
[travis-ci] fcrepo4/fcrepo4#2331 (master - 11ab17c : Esmé Cowles): The build passed.
[travis-ci] Change view : https://github.com/fcrepo4/fcrepo4/compare/e1cfab02235d...11ab17c129ae
[travis-ci] Build details : http://travis-ci.org/fcrepo4/fcrepo4/builds/35120717
* travis-ci leaves
* ksclarke joins10:17
<cbeer>ajs6f: ping?10:18
<cbeer>ajs6f: as i mentioned on the call, azaroth and I (mostly azaroth) has been figuring out LDP and what we need to do to fully support LDP containers10:19
<ajs6f>right on, brother.10:20
<f4jenkins>Yippee, build fixed!
Project fcrepo4 build #2119: FIXED in 13 min: http://jenkins.fcrepo.org/job/fcrepo4/2119/
<cbeer>ajs6f: one of the conceptual things LDP does, that we don't, is distinguishes between RDF resources, non-RDF resources, and RDF resources that are containers10:21
(right now, we pretend every fedora object is a container, and only datastreams are non-rdf resources)
<ajs6f>cbeer: It makes it possible to distinguish between them. It never became clear to me from our conversation whether it _requires_ that distinction.
<pivotal-bot__>A. "Banjaxel" Soroka finished "Remove undeclared but thrown exceptions, other cruft" https://www.pivotaltracker.com/story/show/7867187010:22
<cbeer>ajs6f: i think we've determined it is required, and i think azaroth has taught me to appreciate the distinction.
<ajs6f>Okay. So what requirements does that levy on the API? Mehods to construct non-container resources?10:23
<cbeer>ajs6f: the other thing we don't do is distinguish between containment triples and membership triples (we just confuse the two into fcrepo:hasChild and call it good)
<ajs6f>cbeer: (I do want you to convince me sometime, but right now I want to move quickly onto what the pragmatic consequences are.)10:24
cbeer: Again, azaroth has demonstrated that the distinction is necessary for compliance?
<cbeer>ajs6f: and/or to our annotations use case
ajs6f: i'm trying to figure out if i can get this nice diagram somewhere shareable.10:25
<ajs6f>cbeer: That's a real nice use case. Hate to see anything happen to it.
cbeer: I guess we may as well pay the LDP protection money.
<cbeer>ajs6f: especially now that azaroth officially loves LDP.10:26
ok google docs, you win. i'll just screenshot it and put it somewhere.
<ajs6f>He's probably just finding it a pleasurable shock after dealing with Bibframe to deal with something that actually makes sense.
Some kind of sense, anyway,
<cbeer>ajs6f: although i think azaroth officially loves bibframe too.10:27
probably in a similar way... although LDP seems pretty responsive to his questions.
ajs6f: https://cloud.githubusercontent.com/assets/111218/4250964/030f9fc2-3a89-11e4-9aeb-6ba9df13a117.png10:28
cbeer: That's the annotation use case?
<cbeer>ajs6f: the diagram is a little bit out of date (because you do have to make at least 2 HTTP requests to build out the colored nodes, but..)10:29
ajs6f: the annotations use of LDP, yes.
<ajs6f>cbeer: Cool. Let me stare at that with an intelligent expression on my face for a while.
<cbeer>ajs6f: so, the thing LDP offers (that we don't support at all) is that membershipRelation/membershipResource stuff.
<ajs6f>cbeer; Because we only thought to allow one kind of membership relation hard-coded, right?10:30
* awead leaves
<cbeer>ajs6f: so you can POST that MP3 to the container so wisely named /a/1/b, and LDP will take that, store it (somewhere), and all the membership relation oa:hasBody to the annotation /a/1
ajs6f: exactly.
<ajs6f>But the use case requires not just that there be multiple membership relations, but that the framework itlse handle them?10:31
* awead joins
<cbeer>ajs6f: exactly. you could ignore all of LDP and just PATCH the relationships on the annotation to your hearts content.
<cbeer>ajs6f: with LDP (and the thing I didn't appreciate until this week), your clients don't need to care one bit that they're doing linked data.. they're just doing basic CRUD operations that turn into linked data.
<ajs6f>(This is starting to sound like we're going to have to keep some kind of registry of membership relationships.)
So unless the framework actually does handle the "non-system" membership relationships, there's just no value add for using Fedora.10:33
You might as well use WebDAV.
(API-wise, that is.)
<cbeer>right. and i think annotations is a good case where the linked-data-ness is (sometimes) incidental, and supporting dumb clients that can speak CRUD would be nice10:34
<cbeer>ajs6f: so, pragmatic consequences:
<ajs6f>Okay, I buy it. We don't have to do the disinction, we just have to do it if we want to do anything useful.
<cbeer>- FedoraObject and Datastream need a refactor into Object, Datastream, and Object > Container.
(I don't think that one is too bad.. and FedoraObject/Datastream need some help anyway)10:35
<ajs6f>And we have to make it possible to create both Object and Object mixin COntainer.
(And add code to make sure that they behave all the way through the HTTP and Java APIs like they should.)10:36
<cbeer>yep. probably a rewrite of http.a.FedoraContent and http.a.FedoraNodes
<ajs6f>Do you buy the idea of a registry of non-Fedora-spec'd membership realtionships?
Or is there a less-centralized architecture that we could choose...?10:37
<cbeer>i think we should also split the LDP REST methods into a new maven artifact (fcrepo.http.ldp.api) and include that in the http api module.
ajs6f: i think the membership relations can just live on the containers.10:38
ajs6f: and for all we care, they can just user-modified
<ajs6f>So either 1) http-api extends ldp-api, or 2) My preference: there're other modules (probably mirroring the API partition) that get combined into http-api.
<cbeer>and we don't care one bit what the relations are, because we only concern ourselves with ldp:contains for management operations
ajs6f: +1 to splitting http-api many ways.10:39
especially if it aligns with the spec writing
<ajs6f>cbeer: So we have some kind of internal-ish multivalued property on Container: "hasMemberShipRelationships" and when rendering a represetnation, we match that against the user-created properties to discover which ones end up being declared as LDP memership properties.
cbeer: I like the fact that the split-out modules are going to be nice and small. Tasty, tasty testability.10:40
<cbeer>ajs6f: we don't care about membership properties, except for reproducing them as part of the membership resource's representation.
<ajs6f>cbeer: But don't we have to produce some LDP-specific triples to identify them as membership relationships, so that clients can act that way?10:41
Let me see if I can find them...
<cbeer>ajs6f: nope. ldp:contains is the only LDP-specific triple we need.
ajs6f: i think this was far more confusing in earlier LDP drafts
<ajs6f>cbeer: Wow. Now I'm completely confused again. Aren't we already doing this?10:42
<cbeer>ajs6f: or azaroth is much better at reading specs. or both.
<ajs6f>cbeer: If they've updated the spec, I should go read it before trying to understand.
<cbeer>ajs6f: nope. we cheat. our containers point at themselves for the membership resource, and have a static member relation.
* scossu joins
<cbeer>(which the spec lets us do.. but we don't get anything useful by doing that)
ajs6f: we're essentially doing ldp basic containers now (but pretending they are direct containers)10:43
ajs6f: and we want to be doing direct containers to make azaroth happy, because he cares about the semantic relationship between his objects.10:44
<ajs6f>cbeer: Okay, so how are the membership triples distniguished in any way from any other kind of triple?
<cbeer>ajs6f: they aren't.
<ajs6f>So how do they acquire any semantics? Or am I just supposed to know about that from out-of-band info like an ontology?10:45
<cbeer>ajs6f: out-of-band, i think. when you create an explicit container, you'd also say <> ldp:hasMemberRelation my:MemberPredicate10:46
(or accept our entirely reasonable default)
ajs6f: because fcrepo4 doesn't care what those relationships are.. it's not part of our management path, we just need to produce the correct relations on the resources.10:47
<ajs6f>Ah! That (that triple) is the reason I think we need to track which properties are membership properties. Without tracking them, how do we know what triples of that form to generate. And without those triples, are we doing a properly RESTful (hypertext driven) APi?
Oh, wait. You're saying it's the _client's_ job to do that?10:48
To declare those triples?
"when you create an explicit container"— you is the client, in that phrase?
<cbeer>ajs6f: some client, yes.
ajs6f: some LDP aware client, even.
<ajs6f>Oh, okay. So we're really talking about removing a restriction we currently have in place disallowing the creation of those kinds of triples.10:49
(LDP-vocabulary triples.)
<cbeer>ajs6f: a client that isn't aware of LDP just comes along and sees some membership triples asserted (in semantically appropriate vocabularies)
<cbeer>ajs6f: and a client that isn't aware of linked data just comes along and sees a bunch of resources it can CRUD on.
<ajs6f>cbeer: We might want to have some smartness to check the viability of client-supplied triples that declare membership properties. E.g. we don't want to allow:10:50
<cbeer>(our current architecture requires clients be both LDP aware and linked-data aware, i think)
<ajs6f><> ldp:hasMemberRelation jcr:something
Well, I can see the advantage of allowing the client to manage those kinds of semantics. Although there might be advantages in making the container smart enough to help.10:51
But that's hypothetical.
<cbeer>ajs6f: probably true, yes. and we'd need to do property type checking (as we do now) to make sure the predicate can be used to link two objects
<ajs6f>Right. No <> ldp:hasMemberRelation ex:somepropertythatisNumberValued10:52
<cbeer>ajs6f: i think there's a huge advantage, but out of scope for LDP, and something we'll have to figure out
<ajs6f>cbeer: =1
<cbeer>ajs6f: i think our use case for smart containers is to get to the point where we can make a single REST call from an annotation client, ship off e.g. an MP3, and come back with a fully formed open annotation resource.
(with all the appropriate container interactions)10:53
<ajs6f>Yeah. That would be quite cool, but it would definitely mean registering the memerbship semantics somewhere. And lots of work behind that.
<cbeer>anyway, i think i have a functional java IDE now. time to make a mess.10:54
<ajs6f>cbeer: I'm actually thinking of a local use case: adding a page to a scanned manuscript.
Same kind of thing where you'd like the position in container nesting to automagically imply the right semantics of membership.10:55
cbeer: Are you going to factor Container out of Object?
I wouldn't mind seeing Container extend Collection<Object>, for ease of use. Or maybe just Iterable<Object>10:56
<cbeer>ajs6f: i think we need to, yeah. i wonder if we should mirror this LDP class relationship (but i'm not sure i'm ready to go that far..): https://dvcs.w3.org/hg/ldpwg/raw-file/default/images/ldpc-hierarchy.png
ajs6f: making it an iterable sounds easy enough.10:57
<ajs6f>We're almost done. It's a question of whether you distinguish Container's subtypes.
(Almost done meaning that after you factor out Container, we've almost mirrored it.)
<cbeer>ajs6f: Indirect is on the WG chopping block right now.
<pivotal-bot__>Andrew Woods added "Find suitable term for ns#isInFormat predicate" https://www.pivotaltracker.com/story/show/78722532
<cbeer>ajs6f: and Basic is pretty boring, and can just be a special case of DirectContainer, i think.10:58
<ajs6f>cbeer: Interesting. So azaroth's vague promises that we were thinking about possible looking into it at a future date in the future didn't satisfy them. {grin}
<cbeer>(where the membershipResource is the container itself, and the membership predicate is fixed.... which is what we're doing now, after all)
ajs6f: i think i talked azaroth out of wanting them. they're great for people who want to debate httpRange-14 or 303, but probably not practically useful.10:59
at least for an annotation use case.
<ajs6f>And federation makes them less interesting for other use cases. and they would be a pain.11:00
So we're doing to Direct Container.
<cbeer>certainly Container in -kernel, and probably Direct in some ldp module.11:01
<ajs6f>Good point.
I'm starting to wonder whether part of RDFLexicon shouldn't factor out into a new api.ldp module. The LDP stuff, I mean.11:02
<cbeer>ajs6f: +1.
<ajs6f>Our API is tangled with LDP right now, and now is the time to untangle it.
We want it to extend LDP, not mangle it.11:03
<cbeer>ajs6f: or, we want extending LDP to be one option available (and the default).
<ajs6f>cbeer: With the idea that you might replace it with a different CRUD core?
<cbeer>if someone want to take out LDP and use WebDAV + the transactions API, more power to them.
<ajs6f>cbeer: Hm… why not? If we do the job right factoring out LDP, it shouldn't be too hard. In fact, it's a good test as to whether we _did_ factor out LDP correctly.11:04
When we've done that.
We had to dismember Fedora to save it.11:05
* Giulia joins11:06
<cbeer>ajs6f: can you rebase https://github.com/fcrepo4/fcrepo4/pull/466, so i can beg awoods to merge it before i pull fcrepo4 apart again?
<ajs6f>cbeer: I though I did! Are you getting merge errors?11:07
<awoods>cbeer/ajs6f: I was about to make the same request
<cbeer>ajs6f: looks like github is complaining at least.
<ajs6f>Weird. Let me look at it...
It's based on e1cfab02235de324612b3dbfb53af123c59077b3, which is from escowles: Add IT for preserving properties on federated filesystem moves11:08
Isn't that the most recent thing?
<awoods>ajs6f: you are one behind: https://github.com/fcrepo4/fcrepo4/commits/master
<ajs6f>Oh, okay. On sec...
Fixing new merge errors...11:09
<pivotal-bot__>Giulia HILL started "RDF-ify serialization formats" https://www.pivotaltracker.com/story/show/6522140411:20
<ajs6f>Urg, the merge created checkstyle crap. Hang on.11:24
<cbeer>ajs6f: while i'm doing this.. what do you think about trying to un-JCR the interfaces in fcrepo-kernel? worth it?11:25
e.g. make us wrap RepositoryException into our own thing, at the very least.11:26
or does that just make more work for us?
<ajs6f>cbeer: Weird. I was just thinking yesterday the same thing.
Primarily because RepositoryException is not a RuntimeException, which makes us wrap its subtypes in RuntimeException a lot.11:27
Which is not what JAX-RS expects and causes grossness in the exception mappers, especially Wildcard
<cbeer>ajs6f: yeah, i saw that pull request the other day11:28
<ajs6f>cbeer: Are you thinking of a FedoraRepositoryException < RuntimeException?
<cbeer>ajs6f: that would make things easier for us downstream?
<ajs6f>Because I think that's the only way to fix the JAX-RS stuff. Ideally, we would mix in RuntimeExcpetion to RepositoryException, but… Java.
It would clean up the WildcardExeptionMapper.11:29
Get rid of all that type-testing brittleness.
<cbeer>ajs6f: so we need a FedoraRepositoryExceptionFactory, huh?
<ajs6f>Eh? Why? This isn't Spring...
We ust need a bunch of subclasses, which we already have excpet they are currently subclasses of RepoException.11:30
<cbeer>ajs6f: right. don't we need something to pull out the subtypes we care about?
* mickeroo_ leaves
<cbeer>or FedoraRepositoryException.wrap(RepositoryException)?
<ajs6f>JAX-RS will map the most specific type to a mapper. We're already catching RepositoryException and currently wrapping it in RuntimeException. I'm saying that we'd instead catch RepoException and throw one of our specific, semantically-useful expcetions. In the HTTP layer, the expcetion mappers would catch that specific expcetion and do something useful for the client. Like a 40x or whatever.11:31
We don't have to wrap, we have to catch-and-throw.11:32
We can always throw one of our exceptions wrapped around the original, i.e. throw new OurCoolException(RepositoryException e)
But the important point is to throw an unchecked exception that has some real meaning, not RepoException, which is just a wordless scream from the JCR layer.11:33
And is a checked exception.
<cbeer>ajs6f: pragmatically, then.. i want to write this into -kernel-api? String getPath() throws FedoraRepositoryException;11:34
or, because it's a runtime exception, i don't need to care?11:35
<ajs6f>Right. It's unchecked. We're not going to do anything about it except tell the client that they're screwed.
But we want to tell the client that in the most specific way we can, so impl classes should catch RepoException and throw their best guess as to _why_ it happened. That may be just FedoraRepositoryEx, or it maybe a subsclass.11:36
<ajs6f>It's, I think, an effect of the fact that JCR expects to live at the heart of a user-facing application, not a framework like Fedora.11:37
It makes sense to throw checked exceptions in that world, because you expect the client of JCR (the application) to do something about the problem. But we just want to pass the buck to an outer layer.
Hydra may deal with the problem differently that Islandora, etc. And an app built directly over the Fedora API may deal with it differently again.11:38
Finally! Travis passed my code cleanup PR.
awoods: Over to you.11:39
<awoods>ajs6f: got it
ajs6f: did you update your PR?11:40
<ajs6f>Yeah, it passes now for merging.
<awoods>ajs6f: I am not seeing the new commit, do you have a link?
<ajs6f>It's not a new commit. I ammended the one commit in that branch, because it's all the same static import and putting appropriate modifiers on fields stuff.11:41
* scossu1 joins11:42
* scossu leaves11:46
<cbeer>grumble grumble methods only used in tests grumble grumble11:49
<ajs6f>cbeer: Methods visible only for tests, or actually _used_ only in tests?
<cbeer>ajs6f: only actually used in unit tests.11:50
e.g. FedoraObject#getName
<whikloj>awoods: sorry to say I am not feeling confident about a commit today
<ajs6f>cbeer: Oooooh. Grody.
<awoods>cbeer: nuke'm?
<ajs6f>cbeer; Maybe an artifact of some previous factoring.
<cbeer>awoods: gotta find them first... and then decide whether to do it against master, or just add it as part of this massive commit.11:51
(or, what will be this massive commit..)
<awoods>whikloj: cheer-up, you are on next sprint
<ajs6f>whikloj: I can see that you've only recently started working on Fedora.
<cbeer>ajs6f: any thoughts about this base resource? https://gist.github.com/cbeer/a43669b0a295a3ea6d58
<whikloj>ajs6f: because of my guilt?11:52
<cbeer>that seems to be the only good stuff we're using from FedoraResource right now
<ajs6f>cbeer: I have no problem cutting it down. Maybe public interface Resource<T extends Node>?
<whikloj>awoods: just wanted to let you know, learning mockito
<ajs6f>cbeer: Or do we want to be truly agnostic.
whikloj: Because of your fear. Fear is the enemy of code churn.
<cbeer>ajs6f: i was planning to be totally agnostic.. because, if not now, when?11:53
<awoods>whikloj: thanks for the heads-up and realism.
<ajs6f>cbeer: Okay, I'm with you.
<cbeer>(ok, i know when... last year.)
<ajs6f>cbeer: Yeah, but if eddies were here, he would point out that we want to move as fast as we could.
<cbeer>and here we are 2 years later.11:54
<ajs6f>cbeer: And we're moving quickly. https://www.youtube.com/watch?v=AWtCittJyr0
cbeer: Maybe better than Boolean isA(String type);, Boolean isA(Class<?> type);11:55
If that's really for type-checking within the Java type system.
<cbeer>ajs6f: sorry, i was thinking type-checking within RDF <-> JCR mixins11:56
so isA is probably a bad name.
hasType, maybe.
<ajs6f>cbeer: Yeah, I would say that.
ajs6f: if i happened to do s/get//, would anyone care?11:57
<ajs6f>isNew… I don't like it, but I guess we need it.
<cbeer>(none of those supposed getters can ever have setters..)
<ajs6f>cbeer: I wouldn't, because these aren't beans.
<ajs6f>I often do FieldType MyType.field();
<cbeer>ajs6f: or, wait, you don't care, or you wouldn't care if i did?
<ajs6f>If you did. I think it's fine.
<cbeer>sorry, you don't care, or if you were me, you wouldn't.
ok. perfect.
<awoods>glad that got sorted
<ajs6f>If I were you, I wouldn't care if I didn't not care about whether you did.
cbeer: for things that do have setters, consider:11:59
MyType fieldname(fieldvalue); where you return "this" to encourage a fluent style.
Or even use a self-bounded generic.
<ajs6f>I like that, anyway. It lends some concision to a painfully verbose language
<cbeer>ajs6f: ok, one more architectural question.. all our get*Dataset, get*Triples methods are annoying me. is there any harm to collapsing them to RdfStream getTriples(SomeHintAboutTriplesToReturn)12:05
and building a service layer on top for doing updates, etc?
(and, i guess, exposing some sort of add/remove property methods)
<ajs6f>cbeer: That stuff (those divisions) are an artifact of the need to present different views of a resource for different API calls.12:06
The things was...
we wanted to keep that stuff lazy, so as to avoid the performance problems we ran into earlier on.
So we didn't want to go to a style of "get all the triples and filter them",
becaue it could take a long time to get to the end of the stream of triples to get that last one you wanted.12:07
But I don't know if we still need that separation given the current APIs.
<cbeer>ajs6f: i think we probably do, but i propose we just collapse the reads into a single method with some hints about what to retrieve
<ajs6f>Maybe we can have a simple getALLTHETRIPLES() and use that for all of the various reprsentations.
cbeer: Oh, okay. So an enumeration like {VERSIONTRIPLES, HIERARCYTRIPLES...}12:08
and you pass a value of that into getTriples()?
<cbeer>ajs6f: yep. kinda like we do for #getHierarchyTriples already
<ajs6f>(Or not, if you want them all)
cbeer: Yeah, that sounds much cleaner. I like that.
Just watch the types. Ideally… we'd want people to be able to extend that enumeration with new values in extension code.12:09
So maybe use type bounds carefully.
In fact, we might ourselves want to extend it, e.g. with LDPTRIPLES in a hypothetical api.ldp.12:10
<cbeer>ajs6f: sounds good. i don't know how extensions will tap into that chain, but that can be an exercise for the reader.
<ajs6f>cbeer: Yeah, and like I say, when we factor out LDP, we become the readers.12:11
So as long as we are safely pushing off work into an indefinite future, I'm happy.
cbeer: For impl, you might want to let those enumeration values have fields with type references in them, that refer to the types (probably subtypes of RdfContext) that can actually produce that kind of triple.12:12
Or maybe there's a map somewhere with that info.12:13
<cbeer>ajs6f: so, getTriples(HierarchyProducer.class, VersionProducer.class) (with the appropriate abstraction in place, so we're doing something smarter than that..)?
<pivotal-bot__>Andrew Woods delivered "Remove undeclared but thrown exceptions, other cruft" https://www.pivotaltracker.com/story/show/78671870
<ajs6f>cbeer: One last thing that you've probably already noticed: if you're cutting that stuff down in the resource classes, you might as well cut it down in JcrRdfTools, too.
* github-ff joins12:14
[fcrepo4] awoods closed pull request #466: Nonfunctional code cleanup (master...CodeCleanup4Eva) http://git.io/lWK7Rg
* github-ff leaves
<ajs6f>cbeer: Hm.
I dunno. Maybe we _don't_ want to do something smarter than that. Maybe that's the extensibility right there. Like this:
getTriples(Class<? extends RdfContext>...)
The var-arg is there to let you get version _and_ hierarchy triples, but not LDP triples, or whatever.12:15
and the impl just selects out those classes and uses them.
That's extensible, and the bound gives _some_ type safety.
And it would look a bit like the way we use JAX-RS resource classes already, i..e. building URIs off of JAX-RS resource classes.12:16
<cbeer>ajs6f: ok. if i'm not totally crazy, i'll start with that.12:17
<ajs6f>I say go with it, and if we want to be "tighter" with an enumeration, we can factor that in later.
One thing: if you pass no selector, then you should get everything, so that means you'd want to get _every_ subclass of RdfContext and use 'em all. but I don't think that's a problem.12:18
cbeer: For the "get all the triple generators" thing, I'd look at https://github.com/ronmamo/reflections12:28
* dwilcox leaves12:31
<cbeer>ajs6f: https://gist.github.com/cbeer/28475cf64148e37acd97? (minus the unfortunate jena types.. gotta pull up some interfaces from the impl before i can use them)12:33
(all that IdentifierTranslator makes me think we could push that into the constructor..)12:34
* fcrepo-bot joins
<ajs6f>If we keep the resource classes light, I think we could. (Push the id stuff into the constr)12:36
Besides modifying prperties, are we doing anything with teh StatementListeners now?12:37
<cbeer>just modifying. i think we could kill the StatementListener if we did some higher-level manipulation first
<cbeer>make a statement listener that takes an adder/remover, say.
<ajs6f>Well, I wouldn't worry about it now.
<pivotal-bot__>Giulia HILL added comment: "Corrected code for generalization, did a commit - amend, pushed to origin." https://www.pivotaltracker.com/story/show/65221404
<cbeer>and then container is just: public interface Container<T> extends RdfSource<T>, Iterable<Resource<T>>12:39
<awoods>ajs6f: thinking of dealing with the IdentifierTranslator, that approach was good, but does not go all the way with separating internal and external identifiers. In this refactor, is there an opportunity to put that id-translation layer between fcrepo and underlying JCR calls?
<pivotal-bot__>Giulia HILL finished "RDF-ify serialization formats" https://www.pivotaltracker.com/story/show/65221404
<ajs6f>So if I pass in an RdfStream (not a *RdfCOntext, an actual RdfStream) to getTriples, the expcetation is that it's just going to concat any triples in that stream into the return of getTriples?
* dwilcox joins
<cbeer>ajs6f: sure, sounds reasonable, though that's just in there because we don't have an RdfContext interface.12:40
<ajs6f>awoods: I think we could. It would mean developing a lot of discipline in our own code about not making JCR calls. Only making calls to an internal "JCR client" that handled the id stuff.
cbeer: I saw that. I thouht I had made one, but clearly I didn't. I don't think it's a problem.
<pivotal-bot__>Andrew Woods added comment: "In the future, please do not amend commits; rather, add a new commit so it is easier to see the updates/delta�" https://www.pivotaltracker.com/story/show/6522140412:41
<cbeer>there's NodeRdfContext, but there are some *RdfContext classes that are still RdfStreams
<ajs6f>cbeer: yeah, like NamespaceRdfContext. It doesn't rely on a node to produce its triples.
<awoods>ajs6f: I suspect we could support such discipline.
<ajs6f>awoods: I find your suspecting suspicious.12:42
awoods: Anyway, that's what it would take. If you're writing code inside the kernel, don't talk to the JCR, talk to Fedora's abstractions thereon.
(Which would encapsualte the id translation).
<awoods>ajs6f: precisely12:43
<ajs6f>awoods: The id translation stuff was written fairly generically, but the impls are all about RDF (specifically with jena types)12:44
awoods: So we would have to think about what an identifier is.
Actually, some of the id translation stuff actually returns Jena types, like (RDF) Resource.
We would have to separate those from the simpler underlying stuff that just takes and returns strings.12:45
I think that's IdentifierConverter (strings) as opposed to IdentifierTranslator (RDF)
Or we could make a deep committment to URIs and pass those around.
<awoods>ajs6f: yes, if we could have all identifiers boil down to strings, we could easily translate between internal and external representations.12:46
<ajs6f>awoods: We could translate between _representations_. We'd still want to go to RDF impls at some point on the outward path, I think.
<awoods>ajs6f: Would URIs work for JCR paths?
<ajs6f>They have no protocol.12:47
<ajs6f>But I guess they are relative URIs.
Java has no union classes. I hat ethat.
We could do something a little gross intenrally and make a quasi-union type over JCR paths and URIs.12:48
and translate that to RDF in the outer layers.
I honestly don't much like the idea of identifiers being just strings.12:49
There are some semantics I want to make plain about them, internally or externally.
Although I guess JCR Paths-as-relative-URIs might be enough.12:51
It might even be useful. It might remind us never to emit a JCR path out of the kernel without translating it.
<awoods>ajs6f: If we could work out a URI approach, great. But having a true translation layer between external and internal IDs would open some doors.
<ajs6f>awoods: What are you thinking of?12:52
and is there any money in it?
<awoods>ajs6f: auto-generated hierarchy, for one12:53
<ajs6f>awoods: Ya. That's a good one.12:54
awoods/cbeer: Moving the id translation between the domain type system and the JCR would be even better (more concise) than moving it into the constructors of domain types.
BUT. It would make it much harder to let clients choose for a given translation. Which was always part of the purpose of the translation types.12:55
So… who would get to choose translation schemes? The repo admin?
* scossu1 leaves12:56
<ajs6f>Sorry, -the- translation scheme. It's not clear to me how you would use even more than one.
(per repo instance)
I guess you could run multiple Fedoras over one JCR. If we ever get around to doing that.
<awoods>ajs6f: The current translation-selection approach is in spring...12:57
<ajs6f>awoods: But the purpose of passing translators in from way up there was always to allow people to choose from preconfigured options.12:58
Maybe that was too much generality.
<awoods>ajs6f: are you suggesting that we make that choice more user-configurable?
<whikloj>awoods: Problem has arisen where if I pre-validate namespaces I seem to have to modify every test case that tries to create an object or datastream.
* mikeAtUVa joins12:59
<awoods>whikloj: due to mocking?
<whikloj>awoods: Yes
<ajs6f>barmintor: You wrote the original translation layer stuff. Any thoughts about this idea of moving that layer between the JCR and Fedora's basic types?13:00
<whikloj>awoods: Due to how I tried to capture the problem low, it requires adjusting alot of tests.
awoods: Just wondering if I should modify all the tests that now fail and keep moving along13:01
<awoods>whikloj: I can see how that could happen. Was the approach of catching the exception deemed unreliable?
<barmintor>translation of what to who?
<ajs6f>barmintor: Identifier translation. You called it "GraphSubject" way back when. In Canada, I think.
<awoods>whikloj: versus pre-validation
<barmintor>that was to expose FCR4 ids as URIs to be subjects in a graph.13:02
<awoods>whikloj: how many tests are we talking about?
<barmintor>I remember that.
<whikloj>awoods: Pre-validation still throws an Exception to be caught. Just that it is a NamespaceException instead of a RepositoryException13:03
<ajs6f>barmintor: It's all different now, and we're thinking about making it even more different. Are those enough specifics for you?
<whikloj>awoods: Not sure so far I have modified about 6, just when I hit org.fcrepo.storage.policy.FedoraStoragePolicyIT I realized the scope was larger than expected.
<awoods>whikloj: yes, but the other approach was to pass the object path into the JCR and see if a deeper exception is thrown, versus pre-validation.13:04
<barmintor>ajs6f: .
<whikloj>awoods: Not sure I see how that would work. I read it that passing the path to the JCR throws a RepositoryException, which is what is currently happening. No?13:05
awoods: Or maybe I don't understand what you mean by passing it to the JCR.13:06
<awoods>whikloj: yes, but we are not effectively catching and interpreting the nature of the RepositoryException to know if it is related to a bad namespace.
whikloj: my question is, "Was the approach of catching the exception deemed unreliable?"13:07
<whikloj>awoods: I don't think I ever attempted that.13:08
<awoods>whikloj: I am just throwing it out as an alternative13:09
* scossu joins
<ajs6f>barmintor: We thought of translation from/to JCR identifiers as happening at the outer edge of the Fedora world, at the boundary to clients. awoods is ranting and screaming about moving it to the inner edge, where Fedora's Java types meet the JCR. So everything passing through Fedora code would _already_ have been translated, instead of what we have now, which is JCR identifiers passing freely through Fedora code and _then_ being trans13:13
<whikloj>awoods: I see that method as unreliable as the modeshape method (helpfully called "findOrCreateNode") seems to throw RepositoryException for everything.
awoods: ie. PathNotFoundException if the node doesn't exist. RepositoryException if "another" error occurs.13:14
<ajs6f>whikloj/awoods: This is the usual problem. RepositoryException just doesn't mean much beyond "We're all gonna die!" And it's checked.
So you have to deal with it.
<awoods>whikloj: sounds like that means we should go with the pre-validation approach, and update the tests13:15
<whikloj>awoods: does it matter if this makes a much more broad commit?
ajs6f: I blame you for leading me down this dark path ;)13:16
<awoods>whikloj: I don't think so... broad is good if it is helping the world.
<whikloj>awoods/ajs6f: and further down the rabbit's hole I go.13:17
<ajs6f>whikloj: I didn't make you work on Fedora.13:18
<barmintor>ajs6f: I clearly don’t know what is going on, but I think there was something about the identifiers needing to be different contextually that might make that a higher-overhead approach.13:19
* dwilcox leaves13:20
<whikloj>ajs6f: No it was your belief in separation of business logic from resource classes.13:22
<ajs6f>whikloj: That viewpoint is not unique to myself.13:23
<whikloj>ajs6f: I have enough to blame myself for
<ajs6f>barmintor: Yeah, that's the point. I was trying to remember what we were hoping to achieve by bringing that choice out to the client. Letting them choose from different translation regimes?13:24
whikloj: You'll have the quiet satisfaction of knowing that you chose the high road. As you slowly sink in the mire and your own testing mocks mock you.13:25
<barmintor>ajs6f: something about resolvable URIs and multiple front-ends or something
<ajs6f>barmintor: Right. Multiple front ends rings a bell.13:26
<awoods>afk - lunch
<ajs6f>awoods: Multiple front ends on a single repo. ("Hydra: Many heads, one body", or some such nonsense.) Is that a use case? is that something we value?
<awoods>ajs6f: does the current translation scheme enable that?13:27
ajs6f/barmintor: I feel like right now we can translate between http URLs and JCR paths, period.13:28
<ajs6f>awoods: Not quite, but it's a lot closer than what we are talking about doing. The way I understand it, what we are talking abut doing makes that almost impossible, wherreas what we have now could be extended to do that.
awoods: That's true, because those are the only impls we've bothered to write.
<awoods>ajs6f: Right now, we have a tight binding between external URLs and internal JCR paths.
<ajs6f>I could imagine writing a JCR <-> ids in some other system.13:29
awoods: Which bnding we don't want.
awoods: For one thing, JCR Paths are explicitly _not_ identifiers.
They can point at multiple things.13:30
It's not an inverse-functional relationship.
<awoods>ajsf6/barmintor: would it make sense to leave the IdentiferTranslator as-is, but wrap the JCR interfaces?
ajs7f/barmintor: the wrapped JCR would allow for separation in how paths are translated from external URIs to JCR paths.13:32
<ajs6f>awoods: Wrap? With what? Our own types? Would they do translation?
<awoods>ajs6f: yes, wrapping with our own types
<ajs6f>awoods: The question I still have is: who decides on the translation? Is that still coming from an outer layer, like now, or is it no longer a choice we intend to give to the client?13:33
<awoods>ajs6f: I think translation approach should be repo-admin defined.13:34
<ajs6f>awoods: In that case there is no question for me that translation should occur as early as possible, right next to the JCR.
<awoods>ajs6f: does that argue for wrapping the JCR interfaces?13:35
<ajs6f>And Fedora's code should not be all against the JCR API. Just a little piece of it that can handle ID translation (and possible exception translation of the kind that has been discussed this morning) and the rest of the code should write against that.
awoods: Either wrapping them or writing our own ultra-minimal internal API that sits over the JCR API and wouldn't have many more methods than MODE's JcrTools.13:36
<barmintor>awoods, ajs6f: I think another thing about the current approach is that it’s client defined (the subject translation falls out of how the client interacts). I think this was in support of the HATEOS UI.
<ajs6f>Actually, we already use JcrTools in a very similar way.
<barmintor>JcrTools is an abomination.
<ajs6f>barmintor: It's not a good thing, but my point is only that it does 90% of what you want to do with a JCR.13:37
and we wouldn't need much more.
I don't care. Wrapping the JCR API types is fine by me.
<awoods>barmintor: "subject translation falls out of how the client interacts", really? what do you mean exactly?
<ajs6f>subject translation is a key ingredient in building links.13:38
<barmintor>If the client comes at you via http on a certain DNS, the ids are translated in that domain
<awoods>barmintor: yes
<ajs6f>(Because the id translation depends on JAX-RS-injected types that provide you that context)13:39
<barmintor>that kind of thing is hard to do way down in a layer
<ajs6f>That's a really good pont.
* gregjansen joins
<awoods>barmintor: but that is the only translation scheme
<barmintor>it’s also a good pont, b/c the problem is a missing bridge between the http request and the guts of the JCR13:40
* fcrepo-bot leaves
<ajs6f>We only know how to build the RDF URIs that appear in Fedora HTTP responses because of info that JAX-RS provides, _which isn't available in the kernel._
<awoods>barmintor/ajs6f: which is important...
<awoods>ajsf6/barmintor: would it make sense to leave the IdentiferTranslator as-is, but wrap the JCR interfaces?
<ajs6f>awoods: barmintor is pointing out that doing that would mean you would have to pass a key component of the translation in from the HTTP layer anyway. What have you gained?13:41
<awoods>ajs6f/barmintor: are there potentially two translations at play here?
<ajs6f>the abstraction is leaky like a wet paper bag of leaky sieves with a hole in it.13:42
awoods: There are now. That's the difference between current types IdentifierConvertor and ExternalIdentifierConvertor.
Converter. However.
<awoods>IdentifierTranslator (aka HttpGraphSubjects) uses the JAX-RS machinery (UriInfo) to translate to internal paths which are directly mapped into JCR paths13:43
<ajs6f>Identifiertranslator isn't what I am talking about.
Look at the *IdentifierConverter types. IdentifierConverter would be the inner translation, and ExternalIdentiferConverter would the outer one, the one that needs HTTP information.13:44
Actually several IdentifierConverters chained would be the inner translation, but that's incidental.
<awoods>ajs6f: yes, the trouble is that the *Converters do not come into play in all of the places that JCR methods are called directly throughout our code base.13:45
* mikeAtUVa leaves
<ajs6f>awoods: No, but that's why at the start of this conversation, I claimed that if we are interested in moving translation (and now I would say, any part of translation) down the stack, we would have to be disciplined about how we write against the JCR.13:46
That's why.
If we wrapped the JCR types, the wrappers would have the reponsbility to use *Converters. But we would have the responsibility to use the wrappers.
<awoods>ajs6f: we can either be disciplined, or we can only use the wrappers, yes.13:47
<ajs6f>The discipline _is_ using the wrappers and not making direct calls.
<awoods>ajs6f: if we pushed the wrappers into their own maven module/dependency, it would be pretty easy to exclude the propagation of JCR dependencies beyond that module.
<ajs6f>As long as the JCR API packages are in scope at all, there will always be the tempation to just make easy calls against them.
We would have to expose a really useful API on the other side of that module.13:48
<awoods>ajs6f: The API is already there from JCR, we could largely wrap and pass-through
<ajs6f>awoods: I think there's more in it than that, but I'm happy to write you a ticket.13:49
<awoods>ajs6f: this is probably a face-to-face/hackfest issue
afk - lunch13:50
<pivotal-bot__>Stefano Cossu added comment: "This is the node I tested on:13:53
$ curl http://localhost:8180/fcrepo/rest/resources/assets/SI/testExternalCon�" https://www.pivotaltracker.com/story/show/74627750
Esme Cowles added comment: "@stefanoc I think the issue here is that you are linking from an object to the external content. So the reque�" https://www.pivotaltracker.com/story/show/7462775013:58
<cbeer>ajs6f: ok, i'm working on RdfStream getTriples(IdentifierTranslator graphSubjects, Class<? extends RdfStream>... contexts) now, and have a stupid question..14:12
By passing in Class<...>, we're assuming a consistent constructor for those contexts?
<ajs6f>cbeer: Crap. I guess we are. Presumably a no-arg.
* dwilcox joins
<cbeer>would it be better to pass in an actual instance of some class that can spit out an RdfStream?14:13
or should i just hard-code our existing contexts and defer making it right until later?
<ajs6f>cbeer: Well, this is probably in the back of my mind why I thought of an enumeration at first. It's hard coding, but at least it makes the thing a little more explicit.14:14
cbeer: I don't think we should pass in an instance. That puts too much work back on the client.14:15
The whole point was to simplify the client's life, right?
<cbeer>i've lost track of the point. somewhere far down the stack was my LDP alignment.
but if some form of hard-coding is fine and expected (and no different than what we're doing now...), i'll just keep at it.14:16
<ajs6f>It's at least a little better than what we have now, I think, and it puts us on the road to a good bit better14:17
* gregjansen leaves14:41
<cbeer>well, so far so good. after lunch i guess i'll try to tackle separating fedora datastream from its rdf source properties.14:44
<whikloj>Can I safely assume that the "fedora" namespace prefix is always allowed? Or should I check for it as well?14:54
<ajs6f>whikloj: You can always assume that the _namespace_ is allowed. You never want to test on the prefix.
Someone could be using the same namespace under five different prefixen.
<whikloj>ajs6f: Okay14:55
* dwilcox leaves15:01
<pivotal-bot__>Andrew Woods added comment: "The point of this ticket was to resolve the issue detailed in the ticket description, found here: ""15:33
https://git�" https://www.pivotaltracker.com/story/show/65221404
Andrew Woods rejected "RDF-ify serialization formats" https://www.pivotaltracker.com/story/show/65221404
Andrew Woods edited "Remove undeclared but thrown exceptions, other cruft" https://www.pivotaltracker.com/story/show/78671870
Andrew Woods accepted "Remove undeclared but thrown exceptions, other cruft" https://www.pivotaltracker.com/story/show/78671870
Giulia HILL started "RDF-ify serialization formats" https://www.pivotaltracker.com/story/show/6522140415:35
<whikloj>too all the masterful java coders, I have added NamespaceException. But as it is a subclass of RepositoryException. It gets picked up by the wrong mapper, unless (I am assuming) I add "NamespaceException" to all the "throws". Am I sadly correct?15:47
* scossu leaves15:52
<ajs6f>Is NSException a subtype of RepoException. (Because it shouldn't be.)15:57
It should be a subtype of RuntimeException, and more to the point, a subtype of our FedoraRepositoryException.
(Which itself should be the subtype of RTException.)15:58
Anyway, JAX-RS will use the most specific mapper.
Is there a mapper that is spefici to NSEcpetion?
* scossu joins16:04
<whikloj>ajs6f: First I let the javax.jcr.NamespaceException propogate through, perhaps that was an error and I can create a new Exception for that. To the second, I have a NSExceptionMapper perhaps something else is occurring.16:06
ajs6f: however if I am creating a new Exception, then I'll have to add it to the calls anyways as many of the only have RepoException16:07
<ajs6f>whikloj: yes, you don't want to propagate through anything that is a subclass of j.jRepoException, because those are checked exceptions. You want a new exceptioin with the same meaning as NSException but inheriting from RTEception and not RepoException.16:08
whikloj: The key is that if it inherits from RTException (is an unchkeced exception) you _don't_ have to add it to the method signatures.
You just throw it when you need to.
<whikloj>ajs6f: okay, thanks for that.16:09
<ajs6f>whikloj: Does that make sense? Do you understand why we want to move away from subtypes of RepoException?
<whikloj>Because unchecked exceptions do not _need_ to be caught or added to "throws". However is that the preferred method for Fedora? Is see some interesting discussions on pro-con of only RT Exceptions16:12
* github-ff joins16:13
[fcrepo4] ajs6f opened pull request #467: Collectionizing storage policies (master...PolicyContainerCollection) http://git.io/azuTUg
* github-ff leaves
<ajs6f>cbeer: When you have a chance, look at:
I think it's a little better than what's there now, a little clearer. But no hurry.
whikloj: No, it's because of the difference between writing an application and writing a framework, that I mentioned above. Way above.16:14
The expecation with a checked exceptin is that Java code receiving it is going to do something about it.
But that is _not_ what we expect.
We expect to just pass on the information that somethin bad happened.16:15
Back to the original caller. (probably an outer framework like Hydra or Islandora)
<whikloj>ajs6f: this is that client agnostic stuff you where mentioning before?
were not where
<ajs6f>whikloj: Not sure, but I don't think so. That I mentioned today?
Can you show me a link ono http://irclogs.fcrepo.org/2014-09-12.html16:16
for context?
<whikloj>ajs6f: Not sure either, let me look.
ajs6f: I see the discussion between you and cbeer. That's what you are referring to?16:18
<ajs6f>whikloj: Which of the several convs between cbeer and myself?
whikloj: Anyway, it is a little bit about the nature of the client. In the case of a checked exception, you expect the client (the receiver of the exception) to be responsible for dealing with the fallout.16:19
<whikloj>ajs6f: 11:25am
<ajs6f>In the case of an unchecked exception, you do not.
Ok, let me look.
whikloj: Yes, that's it.
It's not agnosticism.
That wold be a position of "We don't _know_ whether the client is responsible."16:20
We _do_ know,.
The (primary) client is not responsible.
The classes receiving that exception are not part of the public APIs.
They are only and merely responsbile for passing on the information that something has gone wrong.16:21
Not dealing with the consequences.
The ultimate client bears that reponsbility, for example by sending a differently constructed HTTP message.
* github-ff joins
[fcrepo4] cbeer created remove-unused-methods (+5 new commits): http://git.io/l1-1VA
fcrepo4/remove-unused-methods eefd5bb Christopher Beer: remove unused FedoraObject#getName
fcrepo4/remove-unused-methods b364a08 Christopher Beer: Replace #getModels with #hasType check
fcrepo4/remove-unused-methods 56bed4d Christopher Beer: remove unused setContent(byte[])
* github-ff leaves
<ajs6f>(One that isn't wrong!)
* github-ff joins
[fcrepo4] cbeer opened pull request #468: Remove unused methods (master...remove-unused-methods) http://git.io/Qz9i0A
* github-ff leaves
<ajs6f>SO… it's right throw unchecked exceptions here.16:22
If we were writing software that presented a final user interface as a complete application, that would be crappy behavior.
It would be like presenting a useless 500 page with a stacktrace to end users.
But we're not.
We're passing along valuable information about what has gone wrong to a layer of the complete application stack that _can_ do something intelligent with that message.16:23
whikloj: Does that make sense?
The key is, checked exceptions imply something about the responsbilities of the client.16:24
<whikloj>ajs6f: I think so, in this case what do you consider the default admin HTTP interface?
<ajs6f>whikloj: A convenience.
<whikloj>ajs6f: Ok
<ajs6f>Anyone who shows that interface to users who aren't familiar with Fedora and comfortable with it deserves all the confused emails and telephone calls they are going to get.16:25
The people using that interface are the kind of people who shouldn't be frightened by 500 pages with stacktraces. They should know how to file a bug.
<whikloj>ajs6f: I meant more in the "use unchecked because this is middleware" argument, but I see your point.16:26
<ajs6f>whikloj: I understood you to mean that. I'm saying that if you go to the admin console of a piece of middleware, you are trading off a curated user experience for the extra power that the admin console gives you.16:27
<whikloj>ajs6f: gotcha16:28
<ajs6f>I like to be able to rely on message queues to run my workflows.
But I don't want to go to an ActiveMQ or Sonic console and type machine-readable messages into them.
And I sure as hell don't want my users to do that.16:29
I'm out for the weekend. Good luck, whikloj. You're working on Fedora, so you'll need plenty of luck.16:32
* ajs6f leaves
<whikloj>ajs6f: cheers
* ajs6f joins16:34
whickloj: One last thing. If you want to think completely different about exceptions, try:
It's a much larger POV.16:35
* ajs6f leaves
<Giulia>awoods - Re: RDF & serialization: if the subject is a uri but not a export, you still want the uri returned, correc?16:58
* awead leaves17:04
<awoods>Giulia: I am currently in and out... but can you be more specific?17:21
* nikhiltri joins17:22
<Giulia>awoods - in ViewHelpers.java https://github.com/fcrepo4/fcrepo4/pull/227/files#diff-d2db406e1c0a8996c035d902dbfd0d16R147 the subject.isURI() still should return the URI if it's not an export17:25
* jcoyne leaves17:27
<pivotal-bot__>Stefano Cossu added comment: "@escowles It works with a datastream node. Thanks." https://www.pivotaltracker.com/story/show/7462775017:28
<awoods>Giulia: yes, if the logic is unable to determine that the subject has a serialization, and that serialization has a label, then fall back to return subject.getURI()17:37
<pivotal-bot__>Andrew Woods accepted "Seamless external content" https://www.pivotaltracker.com/story/show/7462775017:38
* Giulia leaves17:45
* Giulia joins
* whikloj leaves17:52
* mickeroo joins18:00
* nikhiltri leaves18:04
* scossu leaves18:08