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

Using timezone: Eastern Standard Time
* kaarefc joins00:29
* kaarefc leaves
* kaarefc joins00:56
* kaarefc leaves01:41
* fcrepo-bot joins02:04
* ksclarke leaves02:14
* kaarefc joins02:19
* kaarefc leaves02:25
* kaarefc joins02:30
* fcrepo-bot leaves03:06
* fasseg joins06:33
* fasseg leaves06:54
* fasseg joins06:55
* ajs6f joins08:41
* awoods joins09:00
<ajs6f>awoods: ping?
<awoods>ajs6f09:01
<ajs6f>What I suggested in my email of this morning re: the message format: do you buy that? Because that's a very quick fix that would unblock me.
(Dropping resource typ.)
<awoods>ajs6f: I like the idea of not arbitrarily tying ourselves to the legacy message format. There is a less impactful, yet related change being proposed by osmandin's work. Could you give this a quick look: https://www.pivotaltracker.com/story/show/6115284209:04
<pivotal-bot>bug: Fix integration test AtomJMSIT exception related to truncated messages (finished) / owner: Osman Din
<ajs6f>awoods: osmandin's PR is a good thing, but tt's not clear to me that it fixes the problem.09:06
awoods: He's still going back to the repo for the rsource type.
And when there's no resource there any more...
<awoods>ajs6f: right, but it raises the issue of modifying the message format.
<ajs6f>(We will know that my/nbanks problem is fixed when there is an integration test that checks for messages emitted on deletion.)
awoods: Sure… but it doesn't do that. It uses a different (presumably better) library to emit the same format.09:07
I definitely like the PR. If the new library is stronger, that's a good thing.
<awoods>ajs6f: Did you read the comments on that ticket?
* ksclarke joins09:08
<ajs6f>awoods: Yes, and the PR.
He's changing the XML a bit, but the same info is there.
I want to change the info itself.
* kaarefc leaves09:10
<ajs6f>Thinking about it from the client's POV:
<awoods>ajs6f: Right. Do you have a sense of the impact of such an update would be on clients? such as the jms-indexer?
<ajs6f>it's the difference between changing the message receiver to parse differently, and changing the workflow driven by the message recevier.
awooods: For the JMS indexer, nil. You don't need the type of a resource to remove it from an index.
Or at least I can't imagine an index so badly designed so that you would.09:11
For arbitrary legacy workflows...?
<awoods>ajs6f: Currently, the jms-indexer is making a query back into the repo on each message, no?
<ajs6f>awoods: Right, but that's trivial to adjust so that it only queries on updates. I've already written that.
<awoods>ajs6f: What does the jms-indexer need from the original message? I would like to discuss what a new message format would contain.09:12
<ajs6f>The contract for indexers doesn't include a resource representation as parameter for remove(), which is correct.
<awoods>ajs6f: We should not limit the scope of discussion to "delete"09:13
<ajs6f>For update(), resource identity and representation, for remove(), just identity should be enough, and that's what the contract currently specifies.
<awoods>ajs6f: What elements would you recommend the new message format contain?09:14
<ajs6f>awoods: But that's the problem in the indexer. This problem doesn't exist for update. I'm happy to talk about the message format more generally (as described in my email), but I'd also like to unblock this work and do a good indexer before the end of the month.
Resource identity, timestamp, resource location (which, if the identity is an URL, _is_ the identity, event type.09:15
<awoods>ajs6f: So your suggestion is to keep the message the same, but just drop the resource-type?
<ajs6f>That's an event pblication. Adding anyting to that (like resource type) is info you should be able to get from the repo, if that's what you need.
awoods: No, there are other things in the format we don't need, like who did something to produce the event, but that's a secondary matter to me at the moment because it's available from the JCR event, so it's not blocking the work.09:16
awoods: What I can't abide is the inclusion of info that isn't present in the JCR event.
<awoods>ajs6f: Resource-type is the only such example?09:17
<ajs6f>It's the first one I found.
I didn't get any farther.
Or Further.
http://www.youtube.com/watch?v=EBHLcBxQZiM
Here's the format:09:19
<?xml version="1.0" encoding="UTF-8"?>
<entry xmlns="http://www.w3.org/2005/Atom
       xmlns:fedora-types="http://www.fedora.info/definitions/1/0/types/
       xmlns:xsd="http://www.w3.org/2001/XMLSchema>
  <id>urn:uuid:3773e144-1b63-4dde-8786-464243af9186</id>
  <updated>2008-04-14T22:35:13.953Z</updated>
  <author>
    <name>fedoraAdmin</name>
    <uri>http://localhost:8080/fedora<;/uri>
  </author>
  <title type="text">purgeObject</title>
  <category term="demo:5" scheme="fedora-types:pid" label="xsd:string"></category>
  <category term="purge message" scheme="fedora-types:logMessage" label="xsd:string"></category>
  <category term="false" scheme="fedora-types:force" label="xsd:boolean"></category>
  <summary type="text">demo:5</summary>
<awoods>ajs6f: This is a good time to change the message format. Could you give it a slightly more thorough review and suggest an updated set of elements... and ideally add it to the wiki.
<ajs6f>k
Where?
In a design doc?
<awoods>Design - Messages
?
<ajs6f>k
Got a quick meeting. bbl09:20
* ajs6f leaves
* ajs6f joins09:22
* nbanks joins09:31
* kaarefc joins09:40
* osmandin joins09:56
* tecoripa joins
* ermadmix joins10:02
<tecoripa>fasseg: Re: benchtool changes. I'm not entirely thrilled with the idea of generating a new random byte offset every time the random byte array gets depleted. The whole point of the change is to avoid the overhead of getting random data while in the midst of performance testing. I'd prefer to load the entire array up front, and if the heap blows up, that happens immediately, and the user will simply need to increase the heap size to handle th10:10
<fasseg>so no testing with files larger than heapsize? soryy but i think that's not the way to do it10:11
<pivotal-bot>A. "Killmation" Soroka added "Produce architecture/design doc for workflow messaging" https://www.pivotaltracker.com/story/show/61732296
A. "Killmation" Soroka started "Produce architecture/design doc for workflow messaging" https://www.pivotaltracker.com/story/show/61732296
* osmandin leaves10:12
<fasseg>and if the rng usage is just is size/buf.length it's a very *very* small amount of random numbers generated if buf.length is relatively large.
<tecoripa>fasseg: are you thinking of the large file test case? the problems of doing performance testing with, say, a 30GB file?
<fasseg>yesp
* osmandin joins
* ajs6f leaves10:13
<tecoripa>fasseg: got it. What if we just generate a small amount of random data (say, 1K), and just repeate/concatenate it over and over until we get the datastream size?
<fasseg>and we could even create a set of random numbers at the start and just iterate over them, so there's no rng generation at all in the streaming
<tecoripa>fasseg: jinx :)
<fasseg>tecoripa: that's what I meant in hte comment Im just creating code which takes a random byte array and only create one random offset ech time the fixed size random buffer gets depleted10:15
<tecoripa>ah, okay. I thought you meant to create a *new* random stream of data when the buffer is depleted.
<fasseg>nope just one at program start10:16
check the branch I just pushed (Not completely done yet): https://github.com/futures/benchtool/commit/cf360cc2f4a5cf33d3d28e473dc5247c20c7230f10:17
<tecoripa>fasseg: okay. on another note... one of the changes I made this weekend to correctly report avg. processing time *per thread* didn't make it into the code, so I had to do another commit to my topic branch in my fork. Shall I generate a new pull request, or just send you a link to the change I made (it's only a few lines).10:18
* kaarefc leaves10:19
<fasseg>tecoripa: I saw the change in PR....I think a PR is a bit overweight for that ;) Want me to just add it to my work?
<tecoripa>fasseg: yeah, that would be great, if you don't mind
fassge: you may also want to merge in my other changes to BenchToolFC3 and BenchToolFC4, to get all the changes to the the time measurements and calculations.10:20
<fasseg>tecoripa: sure will do...
<tecoripa>fasseg: you may have already caught this, but it looks like your method signatures don't match for your new BenchToolInputStream constructor: the constructor has a third param, the random bytes, but that's not being set in the call to the constructor in BenchToolFC3 and BenchToolFC410:25
* ajs6f joins
<fasseg>tecoripa: yep still working on that, doesn't compile either, justed wanted to show you how I wanted to implmement it...10:26
<tecoripa>fasseg: ah, okay. While we're on the subject of benchtool, I've been noticing some oddities when running it with multiple threads:10:27
1) during ingest, it seems like the first X objects, where X is the number of threads, always return a 404 not found.10:28
<fasseg>tecoripa: yeah Ill guess we have to synchronize access to the pimitives now that the threading got more complex...
tecoripa: Oh I did not notice that..10:29
<tecoripa>2) and during deletes, there's always an exception thrown that there's no DS1 datastream object to delete.
<fasseg>tecoripa: Oh I didn't even check out the additions esme made yet, Im only doing ingests, I'll have to take a look at that ;)10:31
<tecoripa>fasseg: yeah, I think benchtool could use a second round of tender loving care these next few days. I'm happy to help with that. Once you have a second iteration ready to go, I'll add support for authenticated requests to it, so I can continue with my AuthZ testing.10:36
<fasseg>tecoripa: hehe minds that think a like, I just opened a clean up branch....
tecoripa: Ill add a ticket and assign it to me
<tecoripa>fasseg: sounds good.10:37
<pivotal-bot>Frank Asseg added "Clean up bench-tool" https://www.pivotaltracker.com/story/show/6173501010:39
Frank Asseg started "Clean up bench-tool" https://www.pivotaltracker.com/story/show/61735010
Scott Prater added comment: "@fasseg: also to address -- 404 not founds, during multithreaded ingests and deletes" https://www.pivotaltracker.com/story/show/6173501010:43
A. "Horbulaco" Soroka edited "Produce design doc for workflow messaging" https://www.pivotaltracker.com/story/show/6173229610:46
A. "Horbulaco" Soroka finished "Produce design doc for workflow messaging" https://www.pivotaltracker.com/story/show/61732296
<ajs6f>awoods: ^^^ Take a look.
<awoods>on a call
<ajs6f>HOLY CRAP!
awoods is NEVER on a CALL!
<barmintor|turkey>so this is a thing I canot figure out:10:47
<ajs6f>What we're all doing here?
* escowles joins
<barmintor>Well, yes, but ALSO
on that dataset I created last week, I cut off profiling at about 1/3 of the set10:48
FedoraContent.create invocation count: 336
^^ as expected
<ajs6f>Set of a thousand?>10:49
<barmintor>Yes, 1/3 of a set of 1000
but ISPN.BsonWriter.write invocation count: 12.8M
I presume this is buffered writing10:50
<ajs6f>Is ISPN chunking?
<barmintor>but it makes me itch a little bit
<ajs6f>Doesn't it chunk on some relatively small size?
<barmintor>ajs6f: yes, but here's why I'm troubled:10:51
<ajs6f>Because of those Game of Thrones goons buying all the Ommegang goodness out from under you?
<barmintor>NO
<ajs6f>:)
<barmintor>MODE.NameValueFactory.create invocation count: 15.6M
MODE.JcrSession.cachedNode invocation count: 5M10:52
<escowles>barmintor: so maybe there's some property (like last-modified?) getting update with each chunk being written
<ajs6f>does it have to do with all the system nodes MODE creates for any "user" node? There are a lot of them and we don't have anything like a good understanding of all MODE does for the creation of a single node.10:53
Maybe we can check with MODE to get some sense of what we should expect from the creation of a single node, single binary, etc...
although 300 -> 5M seems kind of crazy.10:54
~17,000 system nodes per user node… that can't make sense.
<barmintor>fcrepo4.DefaultFilter.apply invocation count: 2.5M
^^ that
<ajs6f>That indicates 2.5M JCR events published for the creation of 300 nodes?10:55
<osmandin>afk
<ajs6f>That does seem wack.
<barmintor>fcrepo4.VersionService.checkpoint invocation count: 2.5M
<ajs6f>Whhhhaaaaa? I feel like Shaggy when he and Scoob first see the monster.10:56
<barmintor>(that makes no sense to me at all, since that happens in FedoraContent#create)
<pivotal-bot>Scott Prater added comment: "@frankasseg: sample delete exception is at https://gist.github.com/sprater/7751628
" https://www.pivotaltracker.com/story/show/61735010
<ajs6f>barmintor: So we're talking about 300 or so PUTs or POSTs… resulting in 2.5M calls into VersionService… somehow.10:57
tecoripa: That is a well-known problem with eventing.
tecoripa: I have been discussing it with awoods.
<barmintor>which becomes 5M calls to getNode, which becomes 15M calls to NVF.create
<ajs6f>tecoripa: The issue is that our (dumb, written by me) JMS impl calls back to the repo to get info to put in the Atom stream.10:58
<barmintor>(well, 7.5M, the other half are in the chain resulting from DefaultFilter)
<ajs6f>tecoripa: When it's a delete operation, the node isn't there any more.
Causing that exception.
<tecoripa>ajs6f: yeah, I suspected it might be something like that.
<ajs6f>tecoripa: We're fixing that. One message at a time. :)10:59
<tecoripa>ajs6f: would the problems you're addressing with the event mechanism also cause 404s when doing ingests with multiple threads?
* jcoyne joins
<ajs6f>barmintor: Is it possible that events exist in the JCR repository, causing some kind of snowballing effect? I would thikn that MODE guys would have noticed that by now.
tecoripa: No, it should only occur on deletes, but that's as far as I understand the problem.11:00
* ermadmix leaves
* mikeAtUVa joins11:01
<ajs6f>barmintor: So improving DefaultFilter fixes half the problem! Yay!
running late to office, will be at standup soon.
* ermadmix joins11:02
<awoods>standup?11:03
barmintor? cbeer?11:04
<barmintor>omw. g+ now, correct?
<cbeer>https://plus.google.com/hangouts/_/calendar/eW91cm1lZGlhc2hlbGYuY29tXzVlYzdpNXQ2Z282dTdidHI4aTVrbGJxOTUwQGdyb3VwLmNhbGVuZGFyLmdvb2dsZS5jb20.opn3ai06k1ge0no877ei3cku4o ?
in which case, i volunteer to drop off.11:06
got nothing to say anyway. jgroups is hard, but i didn't go shopping.
* ajs6f leaves11:07
* ajs6f joins11:11
<pivotal-bot>Benjamin Armintor accepted "Run profiler on singleton cachestore on 2954c467f" https://www.pivotaltracker.com/story/show/6158055011:12
<cbeer>escowles: did you drop intentionally?11:13
<escowles>no -- last thing i heard was "looks like we can support 10 people"
<awoods>can you rejoin, escowles?
* escowles reconnecting
<pivotal-bot>Benjamin Armintor added "Figure out exploding calls to JCR internals" https://www.pivotaltracker.com/story/show/6173901011:14
Benjamin Armintor started "Figure out exploding calls to JCR internals" https://www.pivotaltracker.com/story/show/61739010
<escowles>ok, now i'm seeing 11 people in the hangout
<pivotal-bot>Scott Prater added comment: "@frankasseg: sample multithreaded ingest exception is at https://gist.github.com/sprater/7752060" https://www.pivotaltracker.com/story/show/6173501011:22
Scott Prater added comment: "taken up by @frankasseg in ticket https://www.pivotaltracker.com/story/show/61735010" https://www.pivotaltracker.com/story/show/6156857811:25
Scott Prater added comment: "No Authz tests for benchmark purposes are completed and posted: https://wiki.duraspace.org/display/FF/Auth..." https://www.pivotaltracker.com/story/show/5941731411:27
<barmintor>This is definitely not a standup item11:30
<escowles>barmintor: but this is sprint planning...
<barmintor>escowles: Oh right, my bad11:31
<ajs6f>https://wiki.duraspace.org/display/FF/Design+-+Messaging+for+Workflow
<pivotal-bot>Scott Prater added "Document servlet container authentication configuration" https://www.pivotaltracker.com/story/show/6174090211:33
Chris Beer estimated "Fix up fcr:datastreams for a path-based world" as 3 points https://www.pivotaltracker.com/story/show/6087699011:35
Chris Beer estimated "Fix content returned in fcr:workspaces" as 1 point https://www.pivotaltracker.com/story/show/60878838
Chris Beer edited "Fix up fcr:datastreams for a path-based world" https://www.pivotaltracker.com/story/show/60876990
Chris Beer edited "Fix content returned in fcr:workspaces" https://www.pivotaltracker.com/story/show/60878838
Chris Beer edited "Fix export URL" https://www.pivotaltracker.com/story/show/60883752
Chris Beer edited "Normalize responses for Nodes with a trailing slash" https://www.pivotaltracker.com/story/show/60883814
Chris Beer edited "Remove double Expires header from fcr:tx response" https://www.pivotaltracker.com/story/show/6088580811:36
Chris Beer edited "Preserve uploaded file name as a node property (at least from the HTML UI; maybe more globally)" https://www.pivotaltracker.com/story/show/61500736
Chris Beer added comment: "@ajs6f is this done in https://github.com/futures/fcrepo4/blob/master/fcrepo-http-commons/src/main/java/org/f..." https://www.pivotaltracker.com/story/show/5993921811:38
Chris Beer edited "OPTIONS support on LDP Resources" https://www.pivotaltracker.com/story/show/5429290411:39
Chris Beer edited "MODE-2098" https://www.pivotaltracker.com/story/show/6105106011:40
A. "Horbulaco" Soroka added comment: "There _is_ a MessageBodyWriter<RdfStream> there, and it is in use correctly. I think we can close ..." https://www.pivotaltracker.com/story/show/59939218
Chris Beer edited "Update administrative search to support rdf:type translations (or, at least, make sure it works)" https://www.pivotaltracker.com/story/show/60962506
Chris Beer estimated "Update administrative search to support rdf:type translations (or, at least, make sure it works)" as 0 points https://www.pivotaltracker.com/story/show/60962506
Chris Beer edited "Update node COPY/MOVE to be cross-workspace ready" https://www.pivotaltracker.com/story/show/6088732211:41
Chris Beer edited "Fix JMS reporting for item remove events" https://www.pivotaltracker.com/story/show/6161756811:42
Chris Beer edited "Preserve uploaded file name as a node property (at least from the HTML UI; maybe more globally)" https://www.pivotaltracker.com/story/show/61500736
Chris Beer edited "Fix o.f.k.o.SimpleObserver so it doesn't blow the heap out with large volumes of objects" https://www.pivotaltracker.com/story/show/61482610
Chris Beer edited "Test a federated Fedora instance serving a file larger than 100gb" https://www.pivotaltracker.com/story/show/61119370
Chris Beer edited "MODE-2098" https://www.pivotaltracker.com/story/show/6105106011:43
Chris Beer edited "benchmarking filesize limits for REST API file ingest" https://www.pivotaltracker.com/story/show/60974766
Chris Beer edited "Update administrative search to support rdf:type translations (or, at least, make sure it works)" https://www.pivotaltracker.com/story/show/60962506
Chris Beer edited "Acceptance test: versioning" https://www.pivotaltracker.com/story/show/60967090
Chris Beer edited "Update node COPY/MOVE to be cross-workspace ready" https://www.pivotaltracker.com/story/show/60887322
Chris Beer edited "Remove double Expires header from fcr:tx response" https://www.pivotaltracker.com/story/show/60885808
Chris Beer edited "Normalize responses for Nodes with a trailing slash" https://www.pivotaltracker.com/story/show/60883814
Chris Beer edited "Fix export URL" https://www.pivotaltracker.com/story/show/60883752
Chris Beer edited "Version Management" https://www.pivotaltracker.com/story/show/60883346
Chris Beer edited "Fix content returned in fcr:workspaces" https://www.pivotaltracker.com/story/show/60878838
Chris Beer edited "Fix up fcr:datastreams for a path-based world" https://www.pivotaltracker.com/story/show/6087699011:44
<barmintor>escowles: I expect this is a threading issue
<pivotal-bot>Chris Beer accepted "Create MessageBodyWriter<RdfStream> " https://www.pivotaltracker.com/story/show/59939218
<barmintor>that is, # of threads
<pivotal-bot>Chris Beer edited "OPTIONS support on LDP Resources" https://www.pivotaltracker.com/story/show/54292904
Chris Beer edited "Make a JMS serialization that isn't annoying to parse" https://www.pivotaltracker.com/story/show/4562943911:45
Chris Beer edited "Create NodeType page in Adminstration manual on wiki" https://www.pivotaltracker.com/story/show/61554758
<escowles>barmintor: i've seen it with only 1 benchtool thread though -- but maybe benchtool F4 is using threads and the F3 client isn't
<barmintor>escowles: F4 uses many more threads that F3, I meant
<pivotal-bot>A. "Horbulaco" Soroka added comment: "https://wiki.duraspace.org/display/FF/Design+-+Messaging+for+Workflow" https://www.pivotaltracker.com/story/show/45629439
<escowles>barmintor: is there any way to limit that?11:46
<barmintor>escowles: No
ISPN in singleton mode minimizes it
I guess we could try turning some cache expiry stuff off completely
<cbeer>barmintor: expiry or eviction?11:47
<barmintor>cbeer: IDK
<cbeer>(or, we shouldn't have expiry on. that's the thing that deletes content after time T)
<barmintor>whichever one starts the reaper threads :)
<cbeer>barmintor: probably eviction. and there's a PIGGYBACK thread policy in the eviction configuration, i think.11:48
<ajs6f>cbeer/barmintor: There is, but IDK if we're using it.
<pivotal-bot>Chris Beer added "Rename default modeshape/infinispan/etc configurations to xxx-default.yyy" https://www.pivotaltracker.com/story/show/6174244411:49
Chris Beer edited "Rename default modeshape/infinispan/etc configurations to xxx-default.yyy" https://www.pivotaltracker.com/story/show/61742444
<barmintor>cbeer: https://gist.github.com/barmintor/80aa53b6ac7584ee3e3d line 11
that was one of the two changes I mafde to config that bumped single node up ~16%
<cbeer>barmintor: wakeUpInterval=-1 means don't even think about doing expiration?11:50
i'm surprised EvictionStrategy.NONE doesn't imply wakeUpInterval=-111:51
<pivotal-bot>Chris Beer edited "Test different confguration settings of infinispan/jgroups in order to raise performance on the SCC cluster" https://www.pivotaltracker.com/story/show/59401350
Chris Beer edited "Clustered F4 Ingest Benchmarks" https://www.pivotaltracker.com/story/show/60557096
Chris Beer edited "Demonstrate/Document Cluster Recipes" https://www.pivotaltracker.com/story/show/6055745411:52
<barmintor>cbeer: yes, it means just check on access11:53
<cbeer>awoods / mikeAtUVa: at some point soon, could you guys triage the current and backlog tickets? I tried to move tickets and features we mentioned into the backlog, and it suggests we have at least 150% too much work. Hopefully I just moved too many tickets or some of the already started tickets are really close to completion, but..12:01
* ajs6f leaves12:04
<pivotal-bot>Chris Beer added comment: "https://gist.github.com/barmintor/80aa53b6ac7584ee3e3d" https://www.pivotaltracker.com/story/show/6174244412:06
<barmintor>cbeer++ // thanks12:08
* ajs6f joins12:10
<pivotal-bot>Chris Beer edited "FedoraBackupFSIT failure on MacOSX" https://www.pivotaltracker.com/story/show/5799756412:11
<cbeer>escowles: i don't think collapsing properties is a good idea, so there isn't a ticket for that. but all the other tickets are tagged 'user-feedback'12:25
<escowles>cbeer: ok, that makes sense to me
<cbeer>feel free to steal some of the tickets from me, or pull some from the ice box (although the ice boxed ones aren't low hanging fruit, and may have prereqs)12:26
<awoods>cbeer: Can you elaborate on the property collapsing?
<barmintor>afk back in 5
<cbeer>awoods: i don't think i understand their motivations. i suspect they're confusing the fedora 4 UI with an end-user facing admin UI, which (as I understand it) isn't what we're trying to create.12:28
the root node properties are, admittedly, long and nasty because we expose some of the modeshape internals there
* github-ff joins
[fcrepo4] escowles closed pull request #154: Making HTML views editable (master...editable-views2) http://git.io/HCapWQ
* github-ff leaves
<cbeer>but i think regular nodes are less problematic, and should be mostly user-supplied data.
* github-ff joins12:29
[fcrepo4] escowles closed pull request #153: Making HTML views editable (master...editable-views) http://git.io/AZX8uw
* github-ff leaves
* github-ff joins12:30
[fcrepo4] escowles deleted editable-views at 6c5635d: http://git.io/MhtJ_Q
* github-ff leaves
* github-ff joins
[fcrepo4] escowles deleted editable-views2 at f9455a1: http://git.io/tNN5jA
* github-ff leaves
<pivotal-bot>A. "Horbulaco" Soroka added comment: "Depends on https://www.pivotaltracker.com/story/show/61732296" https://www.pivotaltracker.com/story/show/6135191412:32
* github-ff joins12:35
[fcrepo4] escowles created editable-views (+1 new commit): http://git.io/n6xfIg
fcrepo4/editable-views 1f146f1 Esmé Cowles: Making HTML views editable (delete link for user-editable properties, form to add new properties)
* github-ff leaves
<pivotal-bot>Esme Cowles added comment: "I have this mostly-working in the editable-views branch (https://github.com/futures/fcrepo4/compare/editable..." https://www.pivotaltracker.com/story/show/6078128012:36
Esme Cowles unstarted "Make property values in HTML UI editable" https://www.pivotaltracker.com/story/show/60781280
* travis-ci joins12:50
[travis-ci] futures/fcrepo4#1304 (editable-views - 1f146f1 : Esmé Cowles): The build passed.
[travis-ci] Change view : https://github.com/futures/fcrepo4/commit/1f146f1a0323
[travis-ci] Build details : http://travis-ci.org/futures/fcrepo4/builds/14817759
* travis-ci leaves
<bljenkins>Project fcrepo-fixity-corrupter build #512: SUCCESS in 1 min 22 sec: http://ci.fcrepo.org/jenkins/job/fcrepo-fixity-corrupter/512/12:51
<pivotal-bot>Chris Beer added "Expose fcrepo-transform LDPath endpoints as triples.. somehow." https://www.pivotaltracker.com/story/show/6174825412:52
Chris Beer estimated "Expose fcrepo-transform LDPath endpoints as triples.. somehow." as 3 points https://www.pivotaltracker.com/story/show/61748254
Chris Beer edited "Expose fcrepo-transform LDPath endpoints as triples in the HTTP API.. somehow." https://www.pivotaltracker.com/story/show/61748254
<bljenkins>Yippie, build fixed!12:56
Project fcrepo-jms-indexer-pluggable build #302: FIXED in 5 min 58 sec: http://ci.fcrepo.org/jenkins/job/fcrepo-jms-indexer-pluggable/302/
<pivotal-bot>Mike Durbin added "Determine best interaction to fetch version from a particular timestamp to support asynchronous external indexing." https://www.pivotaltracker.com/story/show/6174923213:02
<cbeer>brb
<ajs6f>https://www.pivotaltracker.com/story/show/4562943913:03
<pivotal-bot>feature: Make a JMS serialization that isn't annoying to parse (unstarted) / owner:
<ajs6f>escowles: https://github.com/futures/fcrepo-jms-indexer-pluggable/tree/ajs6fThrashing13:04
Badly named.13:05
<cbeer>back13:07
* github-ff joins13:08
[fcrepo4] ajs6f created FixTheHellOutOfJMS from master (+0 new commits): http://git.io/Okoq7g
* github-ff leaves
* gregjansen joins
<cbeer>ajs6f: sparql and ldpath transforms are handled by the same endpoint13:09
<ajs6f>ermadmix: ^^^
<cbeer>although sparql transforms may be redundant now that we support real sparql queries.13:10
(sparql transforms can include our generated triples.. so maybe there's value there)
but i'd just as soon drop it in favor of admin search.
oh, except sparql transform queries actually use the jena sparql machinery, so you could do everything that's in the spec13:11
<ajs6f>cbeer: It came up in the context of the indexer and trying to keep the pattern uniform, so the transform module seems golden for the purpose.
<cbeer>rather than our subset
<escowles>afk # now i'm going to have to find some tacos...13:12
<pivotal-bot>A. "Horbulaco" Soroka started "Make a JMS serialization that isn't annoying to parse" https://www.pivotaltracker.com/story/show/45629439
<ajs6f>I found mine in my bike bag. It was a wonderful surprise!13:13
<osmandin>afk
<bljenkins>Project fcrepo4 build #1468: UNSTABLE in 24 min: http://ci.fcrepo.org/jenkins/job/fcrepo4/1468/13:14
<pivotal-bot>Eric James added "jms-indexer-pluggable - comply to header messaging" https://www.pivotaltracker.com/story/show/6175030813:16
Eric James started "jms-indexer-pluggable - comply to header messaging" https://www.pivotaltracker.com/story/show/6175030813:17
* ermadmix leaves13:18
<pivotal-bot>Chris Beer started "Fix up fcr:datastreams for a path-based world" https://www.pivotaltracker.com/story/show/6087699013:19
* nbanks leaves13:22
* nbanks joins
* travis-ci joins
[travis-ci] futures/fcrepo4#1305 (FixTheHellOutOfJMS - ceae23e : ajs6f): The build passed.
[travis-ci] Change view : https://github.com/futures/fcrepo4/compare/FixTheHellOutOfJMS
[travis-ci] Build details : http://travis-ci.org/futures/fcrepo4/builds/14819393
* travis-ci leaves
* nbanks leaves13:23
* nbanks joins
* nbanks leaves
<pivotal-bot>Chris Beer unstarted "Fix up fcr:datastreams for a path-based world" https://www.pivotaltracker.com/story/show/6087699013:24
<osmandin>afk 3013:25
<pivotal-bot>Andrew Woods edited "Make a JMS serialization that isn't annoying to parse" https://www.pivotaltracker.com/story/show/4562943913:26
* github-ff joins13:38
[fcrepo4] ajs6f pushed 1 new commit to FixTheHellOutOfJMS: http://git.io/uqTFlA
fcrepo4/FixTheHellOutOfJMS 83ad220 ajs6f: New DefaultMessageFactory using only headers
* github-ff leaves
<bljenkins>Yippie, build fixed!13:46
Project fcrepo4 build #1469: FIXED in 31 min: http://ci.fcrepo.org/jenkins/job/fcrepo4/1469/
Project fcrepo-fixity-corrupter build #513: SUCCESS in 1 min 29 sec: http://ci.fcrepo.org/jenkins/job/fcrepo-fixity-corrupter/513/13:47
* travis-ci joins13:48
[travis-ci] futures/fcrepo4#1306 (FixTheHellOutOfJMS - 83ad220 : ajs6f): The build has errored.
[travis-ci] Change view : https://github.com/futures/fcrepo4/compare/ceae23e7a18b...83ad22001e47
[travis-ci] Build details : http://travis-ci.org/futures/fcrepo4/builds/14820744
* travis-ci leaves
* github-ff joins13:50
[fcrepo4] ajs6f pushed 1 new commit to FixTheHellOutOfJMS: http://git.io/e_rP0Q
fcrepo4/FixTheHellOutOfJMS c1e9267 ajs6f: Licenses...
* github-ff leaves
<bljenkins>Project fcrepo-jms-indexer-pluggable build #303: UNSTABLE in 8 min 29 sec: http://ci.fcrepo.org/jenkins/job/fcrepo-jms-indexer-pluggable/303/13:54
<pivotal-bot>Chris Beer added "Ensure HTML AJAX operations display all errors" https://www.pivotaltracker.com/story/show/6175345813:55
Chris Beer started "Ensure HTML AJAX operations display all errors" https://www.pivotaltracker.com/story/show/61753458
Chris Beer added comment: "Modeshape only raises a generic RepositoryException when building the path fails. I guess we'll want to pre-p..." https://www.pivotaltracker.com/story/show/6150042613:56
Chris Beer added comment: "Modeshape only raises a generic RepositoryException when building the path fails. I guess we'll want to pre-p..." https://www.pivotaltracker.com/story/show/61500426
* gregjansen leaves13:59
* travis-ci joins14:05
[travis-ci] futures/fcrepo4#1307 (FixTheHellOutOfJMS - c1e9267 : ajs6f): The build passed.
[travis-ci] Change view : https://github.com/futures/fcrepo4/compare/83ad22001e47...c1e926723c5d
[travis-ci] Build details : http://travis-ci.org/futures/fcrepo4/builds/14821385
* travis-ci leaves
* github-ff joins
[fcrepo4] cbeer created http-api-fixes (+2 new commits): http://git.io/RriPCw
fcrepo4/http-api-fixes abc3993 Chris Beer: Update AJAX operations to call the ajaxErrorHandler if the operation...
fcrepo4/http-api-fixes ac50c5c Chris Beer: reload the current page after updating datastream content (instead of displaying the content)
* github-ff leaves
<pivotal-bot>Chris Beer added comment: "Fixed in https://github.com/futures/fcrepo4/pull/177" https://www.pivotaltracker.com/story/show/61753458
Chris Beer deleted "Update HTML AJAX call for ingesting objects to raise modal exceptions when ingest fails" https://www.pivotaltracker.com/story/show/6150033014:06
* gregjansen joins14:07
<pivotal-bot>Chris Beer finished "Ensure HTML AJAX operations display all errors" https://www.pivotaltracker.com/story/show/61753458
Scott Prater delivered "Improve benchtool performance: use pre-generated data, don't include object preparation in timings" https://www.pivotaltracker.com/story/show/6156857814:09
* gregjansen leaves14:13
* nbanks joins
<bljenkins>Project fcrepo-fixity-corrupter build #514: SUCCESS in 1 min 34 sec: http://ci.fcrepo.org/jenkins/job/fcrepo-fixity-corrupter/514/14:18
<cbeer>ajs6f: ping?
<ajs6f>pong14:19
<cbeer>ajs6f: i'm struggling with this ticket right now: https://www.pivotaltracker.com/story/show/6150073614:20
<pivotal-bot>feature: Preserve uploaded file name as a node property (at least from the HTML UI; maybe more globally) (unstarted) / owner: Chris Beer
<cbeer>i'm thinking about just adding a property to our fedora:binary mixin
and a new parameter to the REST API for POST .../fcr:content to set it
<ajs6f>So, is the filename a property of the binary, or of the datastream...?14:21
<cbeer>ajs6f: unclear. i was thinking adding it to the binary, though.
* travis-ci joins
[travis-ci] futures/fcrepo4#1308 (http-api-fixes - ac50c5c : Chris Beer): The build passed.
[travis-ci] Change view : https://github.com/futures/fcrepo4/compare/abc3993f6f19^...ac50c5c40af0
[travis-ci] Build details : http://travis-ci.org/futures/fcrepo4/builds/14822096
* travis-ci leaves
<ajs6f>Hm. I don't think binaries _have_ properties, except those supported by MODE outside the JCR.
<cbeer>ajs6f: i think the argument is sometimes the file name carries with it some provenance info we don't want to lose
<ajs6f>(spec, ie.)
cbeer: Sure, I ant to record it too… but I think maybe it should be on the datastream.14:22
<cbeer>ajs6f: nt:resource has mime types and last modified dates by default
ajs6f: and we're already mixing in our checksum stuff
<ajs6f>When we say "binary", are we talking about jcr:content?
<cbeer>ajs6f: i think we confuse nt:resource and jcr:data items in fcrepo4.14:23
<ajs6f>cbeer: That's what I was trying to get at.14:24
<cbeer>ajs6f: i'm thinking about adding a property onto our nt:resource item (stored at ./jcr:content, right?) for this title
not at the nt:file level. but we could put it on nt:file if we wanted, i guess.
<ajs6f>Yeah, that's interesting. the jcr:content guy is not quite a datastream, but not quite a naked bitstream either. I think you're right— that's where the filename belongs.
Wait, there's an ntfile child of jcr:content?
<cbeer>ajs6f: no. jcr:content is a property of nt:file. jcr:content is an nt:resource.14:25
and we expose the nt:file as a fedora:datastream.
and we have no user-modifiable properties on the jcr:content node.
(and, arguably, the uploaded file name isn't user modifiable.. it's just a fact.)14:26
<ajs6f>Right. I think you are correct in wanting to put the filename on jcr:content.
I do think we should write soething somewhere to explain to users what we just clarifed:
<cbeer>ok. as some one-off property (maybe called dc:title... maybe some new fedora:filename property)
<ajs6f>jcr:content is smaller than its datastream, but bigger than its bitstream, and it's the place where non-user-modifiable properties go.14:27
That's the new rul!
rule!
<cbeer>+1
<ajs6f>Yeah, dc:title sounds fine.
We can always specify further later. Or specify more, further along. Or something like that.14:28
<cbeer>ajs6f: i'm only worried about dc:title because it might be confusing to have some dc:titles people can modified and some they can't.
<ajs6f>Then they don't understand the semantics of dc:title, which is purely descriptive and don't include any notion of mutability.14:29
<escowles>it might make more sense to use PREMIS originalName or something like that
<ajs6f>And I will personally visit the workplace of any confused person and explain it to the.
escowles: Is there a decent PREMIS RDF representation?
<escowles>ajs6f: not that i know of (our ontology has some PREMISy bits though)14:30
<ajs6f>Urg.
<escowles>wait, strike that, there is http://id.loc.gov/ontologies/premis.html
<tecoripa>ajs6f: http://id.loc.gov/ontologies/premis.html
beat me to it
<ajs6f>Kevin Ford and crew +++
<escowles>http://id.loc.gov/ontologies/premis.html#hasOriginalName
<ajs6f>Let's import the hell out of that!
<cbeer>cool.
ajs6f: looks like we should use premis:hasSize instead of fedora:size too14:31
<ajs6f>awoods: Immediately begin claiming publicly that we "support PREMIS". When asked questions, point at escowles and run in the other direction.
cbeer: +1
the less fedora -specific vocab, the better.
<escowles>that PREMIS ontology is on my list of stuff to implement once our hydra head is released in january14:32
<tecoripa>fwiw, we're using it already for some name authority/viaf work we're doing, adding some admin metadata datastreams to our Fedora 3 objects14:33
<cbeer>ajs6f: and, no objection to me ignoring their suggested domains, right? we can just pretend someone else asserts nt:resource is a premis:file somewhere else14:34
<ajs6f>We do, in the magical inference-enabled ultra-scalable co-reference store I keep (opens coat and reaches in pocket) "RIGHT HERE!" (throws coat over questioner's head and runs away).14:35
We can keep that assertion in futures/ontology if we want.
And publish i just like all the other bold-faced claims we make about the world.14:36
<cbeer>ajs6f: ok. and no objection to adding some one-off query parameter to the fcr:content endpoint for now?14:37
<ajs6f>cbeer: Is there by any chance a well-known header for that sort of thing?14:38
<cbeer>ajs6f: good point. let me check.
<ajs6f>cbeer: I don't know of one, but then, I wouldn't.
<cbeer>Content-Disposition?14:39
<ajs6f>escowles: That branch for the indexer I pushed?
<escowles>there has to be a standard header for that somewhere -- all of the upload processing systems i know about provide access to the original filename
<bljenkins>Project fcrepo4 build #1471: UNSTABLE in 22 min: http://ci.fcrepo.org/jenkins/job/fcrepo4/1471/
<escowles>ajs6f: that branch is supposed to work once the events are working, right?
<ajs6f>escowles: It occurs to me that the test indexer is fine, and the i-test is fine (IndexerGroupIT), but they might as well be one class.
So that might be clearer.
<cbeer>(although i think content-disposition is for retrieving content, not post/putting it)14:40
<ajs6f>cbeer: Still less nonstandard than a query param of our own specification.
<cbeer>oh, and multipart uploads also use it..
<ajs6f>That's good enough for me.14:41
<cbeer>"The Content-Disposition response-header field"...14:42
<escowles>cbeer: RFC 1867 says clients should use Content-Disposition for uploads: http://tools.ietf.org/html/rfc186714:45
i.e., it's not just for responses
<ajs6f>Is there noting in life uncovered by an RFC somewhere?14:46
<escowles>ajs6f: if the test indexer is internal to the IndexerGroupIT, how do we reference it in the spring config?
<cbeer>escowles: with multipart/* requests
<ajs6f>escowles: Not an internal class— the same class.14:47
IndexerGroupIT implements Indexer
And it would reference itself in the Spring config it uses.
<escowles>ajs6f: okay, so that would make referencing it easier
<ajs6f>(Instead of referencing TestIndexer, which would go away)
escowles: yeah. If you think it's _more_ confusing, then let's don't.14:48
It would also lose the injected Indexer field. It could just say, "this" instead.
<escowles>it would be somewhat clearer in that the test indexer impl. would be in the same place, presumably with a copious javadoc note saying why we're doing it that way
<ajs6f>Yep, exactly.
<escowles>ok, sounds good to me14:49
<ajs6f>Well, if you want to review the PR, you can do that at the same time, or you can review it and then I can do it, or whatever.
<escowles>i can review the PR and add that in at the same time14:51
* nbanks leaves
<ajs6f>escowles++14:53
<escowles>ajs6f: but i'm going to wait for working events, right?14:54
<ajs6f>escowles: Sure thing. Almost there (one more itest to write).
* github-ff joins15:09
[fcrepo-jms-indexer-pluggable] ajs6f pushed 1 new commit to ajs6fThrashing: http://git.io/DijYcg
fcrepo-jms-indexer-pluggable/ajs6fThrashing 0bfb60d ajs6f: Better
* github-ff leaves
<ajs6f>escowles: ^^^ Sorry, just realized I hadn't pushed the last bit.
* tecoripa leaves15:13
<barmintor>man, HttpGraphSubjects is kind of a busybody, isn't it?
<bljenkins>Yippie, build fixed!
Project fcrepo-jms-indexer-pluggable build #305: FIXED in 4 min 43 sec: http://ci.fcrepo.org/jenkins/job/fcrepo-jms-indexer-pluggable/305/
<pivotal-bot>Chris Beer started "Preserve uploaded file name as a node property (at least from the HTML UI; maybe more globally)" https://www.pivotaltracker.com/story/show/6150073615:21
<barmintor>ajs6f: If a lot of the overhead of FCR4 is translating JCR events to Fedora3 events by looking the nodes back up, what would you think of moving that stuff into some kind legacy-api post-op filter that publishes FCR3 events out of whole cloth?15:30
<ajs6f>barmintor: +1. I'm taking the first step right now by introducing better, more lightweight alternative. (SPring test crap is annoying.)
The new message style doesn't suffer from that problem.15:31
<barmintor>ajs6f: I'll just have to believe you on that score
<ajs6f>Which score? That the new format doesn't have that problem? It's easy to prove— it doesn't touch the repo. It only uses the events.
9The JCR Events.)15:32
(I.e. it never looks up a node.)
* github-ff joins15:33
[fcrepo4] ajs6f pushed 1 new commit to FixTheHellOutOfJMS: http://git.io/qE17OQ
fcrepo4/FixTheHellOutOfJMS fc49cc3 ajs6f: Working integration tests\!
* github-ff leaves
<ajs6f>barmintor: Look for yourself if you don't believe me. ^^^
<barmintor>ajs6f: I totally believe you. I just meant "I'm leaving that to you."15:34
"That's your business."
<ajs6f>oh, gotcha. Consider it done.
<barmintor>"Get off my lawn!"
<ajs6f>"But Grandpa Ben, we want to hear about the wonderful 2008 Rodenbach again!"15:35
* github-ff joins
[fcrepo4] ajs6f opened pull request #178: Better JMS format (master...FixTheHellOutOfJMS) http://git.io/BBMy_g
* github-ff leaves
<pivotal-bot>A. "Horbulaco" Soroka added comment: "https://github.com/futures/fcrepo4/pull/178" https://www.pivotaltracker.com/story/show/45629439
A. "Horbulaco" Soroka finished "Make a JMS serialization that isn't annoying to parse" https://www.pivotaltracker.com/story/show/45629439
<ajs6f>cbeer: ^^^ Lemme know what you think.15:36
* github-ff joins15:40
[fcrepo4] ajs6f pushed 1 new commit to FixTheHellOutOfJMS: http://git.io/whpKDg
fcrepo4/FixTheHellOutOfJMS a9be2e5 ajs6f: Better logging and code format
* github-ff leaves
<cbeer>ajs6f: works for me. i wonder if we should pull the header names into a module that consumers could also use15:41
<ajs6f>cbeer: Not sure what you mean… like a client library?
<cbeer>ajs6f: yeah, like we're doing with fcrepo-jcr apparently.15:42
<ajs6f>Or something human-readble, like an HTML page.
cbeer: What do we do with jcrepo-jcr like that?
cbeer: You mean FedoraJcrTypes?
<cbeer>ajs6f: fcrepo-jcr has all our types, eyah.
maybe we should rename fcrepo-jcr something else, and add those constants into that module15:43
<ajs6f>cbeer: Sure, I'll pull those header constants out into an interface like that.
cbeer: Oh, you mean like one great big constants module.
or a constants + configs modules
<cbeer>except not configs, apparently. they used to be in there and then we pulled them back out
<awoods>ajs6f: we moved away from having configs there.15:44
<ajs6f>In the OSGi world, we would expect to find a "fedora API bundle" with interfaces and constants.
fcrepo-api with all the stuff someone else might want to consume or impl themselves.
<awoods>ajs6f/cbeer: maybe renaming fcrepo-jcr to fcrepo-constants
<ajs6f>Fine with me. Only annoyance: means people will have to work across several modules to make changes in one.15:45
Actually, I kind of dislike that.
If we're gong to present a bundle of contracts (including constants) that's great, but just constants doesn't seem worth the bother.
<awoods>ajs6f: for better or worse, fcrepo-jcr is exactly that.15:46
<ajs6f>awoods: No. There are constants all over the place. RdfLexicon, for example.
* travis-ci joins
[travis-ci] futures/fcrepo4#1310 (FixTheHellOutOfJMS - fc49cc3 : ajs6f): The build passed.
[travis-ci] Change view : https://github.com/futures/fcrepo4/compare/c1e926723c5d...fc49cc377ff2
[travis-ci] Build details : http://travis-ci.org/futures/fcrepo4/builds/14826277
* travis-ci leaves
<ajs6f>If you want to make fcrepo-jcr that, okay, we can talk about it, but it's not that yet.15:47
(And I'm not really much in favor of doing that. Not until we have a more coherent and stable API to present.)
(Because constants are only interesting if you are consuming our API or impling our SPI).
<awoods>ajs6f: The question at hand is, "do we pull the new constants out of the fcrepo-jms project or not"?15:49
ajs6f/cbeer: and if so, to where?
<ajs6f>awoods: And I say no, because we don't have anyplace better to put them.
And I don't agree that fcrepo-jcr is a good place.
<bljenkins>Yippie, build fixed!
Project fcrepo4 build #1472: FIXED in 16 min: http://ci.fcrepo.org/jenkins/job/fcrepo4/1472/
<cbeer>awoods: if ajs6f says no, not yet, i'm happy to believe him.15:50
<awoods>ajs6f: Which is fine, the downside being that consumers of jms messages will need to depend on fcrepo-jms, instead of a lighter module.
<ajs6f>I just don't see that as particularly onerous in a Maven world.15:51
<bljenkins>Project fcrepo-fixity-corrupter build #515: SUCCESS in 1 min 35 sec: http://ci.fcrepo.org/jenkins/job/fcrepo-fixity-corrupter/515/
<awoods>If it does not bother you, it is fine with me.
<ajs6f>If you want to do true API bundling (and I think that's great) I can split out a fcrepo-jms-api module with interfaces and constants. _That_ would be where I would put these things.15:52
Then people can depend on that.
<awoods>ajs6f: The -api is a good pattern... but like you said, it is probably fine as is.15:53
<ajs6f>Actually, annoyingly, the only interesting interface in the JMS stuff is not API, it's SPI: JMSEventMessageFactory.
Kind of a bad example. HTTP might be better.
Actually, HTTP is interesting to me as an example of publishing constants, because in a truly RESTful framework we should be able to make them deferencable to their own definitions.15:54
<pivotal-bot>Benjamin Armintor added comment: "1) We should either not use the JCR event bus to emulate FCR3 events, or figure out a way to pass the ..." https://www.pivotaltracker.com/story/show/61739010
Benjamin Armintor added comment: "2) VersionService should have a method to reuse existing nodes rather than only absolute paths and ses..." https://www.pivotaltracker.com/story/show/6173901015:55
Benjamin Armintor accepted "Figure out exploding calls to JCR internals" https://www.pivotaltracker.com/story/show/61739010
* travis-ci joins
[travis-ci] futures/fcrepo4#1312 (FixTheHellOutOfJMS - a9be2e5 : ajs6f): The build passed.
[travis-ci] Change view : https://github.com/futures/fcrepo4/compare/fc49cc377ff2...a9be2e5d8bc3
[travis-ci] Build details : http://travis-ci.org/futures/fcrepo4/builds/14826599
* travis-ci leaves
<bljenkins>Project fcrepo-jms-indexer-pluggable build #306: UNSTABLE in 5 min 36 sec: http://ci.fcrepo.org/jenkins/job/fcrepo-jms-indexer-pluggable/306/
<pivotal-bot>A. "Horbulaco" Soroka added comment: "No idea about VersionService, but the new JMS format should kill the problem in 1). " https://www.pivotaltracker.com/story/show/61739010
A. "Horbulaco" Soroka added comment: "New JMS format = https://github.com/futures/fcrepo4/pull/178 and https://www.pivotaltracker.com/st..." https://www.pivotaltracker.com/story/show/6173901015:56
A. "Horbulaco" Soroka added comment: "Man, I wish we could edit these comments." https://www.pivotaltracker.com/story/show/61739010
A. "Horbulaco" Soroka edited "Self-Hosted Configuration" https://www.pivotaltracker.com/story/show/6025714816:00
<ajs6f>afk bbs16:02
* ermadmix joins
* ajs6f leaves
<mikeAtUVa>Could someone point me to sparql that would add a mixin type to an object?16:06
<cbeer>mikeAtUVa: do we expose that as a SPARQL-modifiable property?16:09
oh, i guess we do
* mikeAtUVa shrugs at cbeer...
<bljenkins>Project fcrepo-fixity-corrupter build #516: SUCCESS in 1 min 4 sec: http://ci.fcrepo.org/jenkins/job/fcrepo-fixity-corrupter/516/16:10
<mikeAtUVa>I'm trying to add a mixin that has an autocreate property and things failed horribly when I posted a CND that added it to the fedora:resource definition, so I'm trying another tack.
<cbeer>mikeAtUVa: if it works, i tihnk it's just <> a <uri/to/mixin/type>16:11
* ajs6f joins
cber: I think this is cool: http://spinrdf.org/. Nothing we want to fool with right now, but we could have a lot of fun with this, fcrepo-transform, and ermadmix's ideas about multi-object eventing.16:13
<bljenkins>Project fcrepo-kitchen-sink build #686: STILL UNSTABLE in 3 min 13 sec: http://ci.fcrepo.org/jenkins/job/fcrepo-kitchen-sink/686/
<escowles>cbeer/mikeAtUVa: so probably "insert data { <OBJ_URI> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <MIXIN_URI> }"
oops, that should be: "insert data { <OBJ_URI> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <MIXIN_URI> . }" // period not optional16:14
<mikeAtUVa>escowles: Thanks, I'll try that...16:15
<awoods>mikeAtUVa: please indicate if it (or something like it) works or not.16:16
<pivotal-bot>Chris Beer estimated "Preserve uploaded file name as a node property (at least from the HTML UI; maybe more globally)" as 2 points https://www.pivotaltracker.com/story/show/6150073616:22
* github-ff joins16:23
[fcrepo4] cbeer created content-disposition (+1 new commit): http://git.io/I611Tg
fcrepo4/content-disposition eb99d16 Chris Beer: Use premis hasOriginalName (and hasSize) predicates on fedora:binary...
* github-ff leaves
* github-ff joins16:24
[fcrepo4] cbeer opened pull request #179: Use premis hasOriginalName (and hasSize) predicates on fedora:binary resources (master...content-disposition) http://git.io/bWv0Og
* github-ff leaves
<pivotal-bot>Chris Beer added comment: "Decision: premis:hasOriginalName" https://www.pivotaltracker.com/story/show/61500736
Chris Beer added comment: "https://github.com/futures/fcrepo4/pull/179" https://www.pivotaltracker.com/story/show/61500736
Chris Beer added comment: "Updated https://wiki.duraspace.org/display/FF/HTTP+API" https://www.pivotaltracker.com/story/show/6150073616:28
Chris Beer finished "Preserve uploaded file name as a node property (at least from the HTML UI; maybe more globally)" https://www.pivotaltracker.com/story/show/61500736
<ajs6f>cbeer: Should we update futures/ontology to show the relationship of the new PREMIS predicates to our classes?16:29
<pivotal-bot>Chris Beer added "Add "flash" messages for AJAX operations in the HTML API" https://www.pivotaltracker.com/story/show/61766654
<cbeer>ajs6f: is futures/ontology now redundant with the fcr:nodetypes endpoint?16:30
<escowles>ajs6f: how much PREMIS do you want? is a fedora Object a PREMIS Object? Is a fedora Datastream a PREMIS File? etc...
<ajs6f>cbeer: Good question: That would be fantastic.
escowles: Those are exactly the questions I was raising.
(Not expecting to answer immediately.)
<cbeer>ajs6f: ah, except futures/ontology has comments and the like for predicates
<ajs6f>cbeer: True, but we could do stuff like that for nodetypes. (I think.)16:31
the jcr stuff doesn't help us much there...
<cbeer>ajs6f: i think node types live somewhere in the JCR tree though
<ajs6f>but we could introduce our own layer of "decoration" that gets added into the publication at that endpoit.
Not by JCR spec, I don't think. maybe MODE does somethinglike that.16:32
<cbeer>http://www.day.com/maven/javax.jcr/javadocs/jcr-2.0/javax/jcr/nodetype/package-summary.html#nt:nodeType
i bet we can't get at them easily, but..
<ajs6f>cbeer: That was my point.
<cbeer>ok. that i'm not sure about.16:33
<ajs6f>They exist as a type, but they don't necessarily exist as instances in the repo. Although MODE may do it that way.
Or to use your language, they exist in JCR, but not necessairly in the JCR tree.
If they do (and the MODE folks don't tell us it's crazy) we could annotate them there.16:34
If they don't (or the MODE folks tell us that such nodes are really internal and dangerous on which to rely) we could introduce a swath of privileged repo that contains ontology.
(Just for the sake of publication, now.)16:35
I would love to kill futures/ontology and let people discover the ontologies in their own repos.
See my comment above about publishing HTTP constants via HTTP. This is the same thing.
<escowles>ajs6f: then we could run a repo at the public URI to serve the ontology...16:36
<ajs6f>escowles: Bingo. And then we all ingest ourselves into that repo, like Tron.
<escowles>yo dawg, i heard you like repositories, so i ingested a repository into your repository...16:37
<ajs6f>That's like putting a portable hole into a bag of holding!
barmintor: C'mon, I know you got that one.16:38
<barmintor>Oh! Oh yeah.
Don't even think about casting rope trick.
* travis-ci joins16:39
[travis-ci] futures/fcrepo4#1314 (content-disposition - eb99d16 : Chris Beer): The build passed.
[travis-ci] Change view : https://github.com/futures/fcrepo4/commit/eb99d16e4725
[travis-ci] Build details : http://travis-ci.org/futures/fcrepo4/builds/14829025
* travis-ci leaves
<ajs6f>I'm no wizard. I'm a fearless half-mermaid ranger, accompanied by my octopus animal companion, Roger.
awood: Can you get some sense (from steering or elsewhere) about what kind of interest is out there in supporting PREMIS at the level escowles just pointed at?16:40
<jcoyne>ajs6f: http://www.youtube.com/watch?v=_PYPfJyIFrA16:41
<ajs6f>jcoyne: That is one repo that is not bound to disk speed.16:43
<bljenkins>Project fcrepo-fixity-corrupter build #517: SUCCESS in 1 min 3 sec: http://ci.fcrepo.org/jenkins/job/fcrepo-fixity-corrupter/517/
<barmintor>Hmm. I appear to have broken everything.16:46
<ajs6f>"Breaking everything, two weeks at a time."
<awoods>ajs6f: It would probably be best for you to explore the community interest in PREMIS support by polling fedora-tech.
<ajs6f>awoods: I don't want there to be any interest. With that in mind, I'm now comfortable that we're already doing more than enough.16:47
<bljenkins>Project fcrepo-kitchen-sink build #687: STILL UNSTABLE in 4 min 58 sec: http://ci.fcrepo.org/jenkins/job/fcrepo-kitchen-sink/687/16:48
Project fcrepo-fedora3-federation-connector build #295: FAILURE in 6 min 13 sec: http://ci.fcrepo.org/jenkins/job/fcrepo-fedora3-federation-connector/295/
<barmintor>I would bet my lunch money that, if we conducted a such a poll, we would see people that wanted a record of PREMIS events around an object from the repo, but few people who cared that it was a vocabulary for event listeners
and the former would be :( when we explained that we had FROZEN THEIR FEATURE OUT16:49
<ajs6f>I brought my lunch today, so I can't get in on this one.16:50
Didn't we intend to do something called "audit"?
<bljenkins>Yippie, build fixed!16:51
<ajs6f>I don't know that we ever did much more than call it, "audit", like a puppy we absentmindedly adopted and never play with.
<bljenkins>Project fcrepo-jms-indexer-pluggable build #308: FIXED in 8 min 39 sec: http://ci.fcrepo.org/jenkins/job/fcrepo-jms-indexer-pluggable/308/
<awoods>ajs6f: Yes, "audit" is the puppy that was not invited to the holiday-release.16:52
<ajs6f>awoods: And PREMIS is a litter-mate.
* osmandin leaves16:56
<mikeAtUVa>esme,awoods,cbeer: the sparql for adding that mixin does work and will find its way into an integration test I'm making and the corresponding walkthrough for versioning that describes one way to create auto-versioning objects.16:57
<ajs6f>out for the day, see 'yall later16:58
* ajs6f leaves
<awoods>That is fancy, mikeAtUVa.16:59
<escowles>mikeAtUVa++ # i never would have thought to try that17:20
* mikeAtUVa leaves17:41
* github-ff joins17:52
[fcrepo4] cbeer force-pushed content-disposition from eb99d16 to 506961e: http://git.io/tmdcfg
fcrepo4/content-disposition 506961e Chris Beer: Use premis hasOriginalName (and hasSize) predicates on fedora:binary...
* github-ff leaves
<pivotal-bot>Andrew Woods added "Determine filesize ingest limit via REST API" https://www.pivotaltracker.com/story/show/6177343017:53
Andrew Woods edited "Determine filesize ingest limit via REST API" https://www.pivotaltracker.com/story/show/61773430
<cbeer>awoods: does that replace https://www.pivotaltracker.com/story/show/60974766?
<pivotal-bot>chore: benchmarking filesize limits for REST API file ingest (unstarted) / owner:
<awoods>cbeer: I think it does.17:54
<pivotal-bot>Chris Beer deleted "benchmarking filesize limits for REST API file ingest" https://www.pivotaltracker.com/story/show/6097476617:55
<awoods>cbeer: thanks
<pivotal-bot>Andrew Woods added "Determine filesize read limit via REST API" https://www.pivotaltracker.com/story/show/61773644
Andrew Woods edited "Determine filesize read limit via REST API" https://www.pivotaltracker.com/story/show/6177364417:56
<barmintor>I think something bad has happened w/ jetty:run, not starting for me18:01
will check tomorrow, good night folks18:02
<pivotal-bot>Chris Beer started "Update administrative search to support rdf:type translations (or, at least, make sure it works)" https://www.pivotaltracker.com/story/show/6096250618:07
Chris Beer edited "Update administrative search to support rdf:type translations" https://www.pivotaltracker.com/story/show/60962506
* travis-ci joins18:10
[travis-ci] futures/fcrepo4#1316 (content-disposition - 506961e : Chris Beer): The build passed.
[travis-ci] Change view : https://github.com/futures/fcrepo4/compare/eb99d16e4725...506961e1c02b
[travis-ci] Build details : http://travis-ci.org/futures/fcrepo4/builds/14834344
* travis-ci leaves
<bljenkins>Project fcrepo-fixity-corrupter build #518: SUCCESS in 1 min 19 sec: http://ci.fcrepo.org/jenkins/job/fcrepo-fixity-corrupter/518/18:16
Project fcrepo-kitchen-sink build #688: STILL UNSTABLE in 3 min 4 sec: http://ci.fcrepo.org/jenkins/job/fcrepo-kitchen-sink/688/18:19
Project fcrepo-fedora3-federation-connector build #296: NOW UNSTABLE in 4 min 54 sec: http://ci.fcrepo.org/jenkins/job/fcrepo-fedora3-federation-connector/296/
* ermadmix leaves18:55
* github-ff joins18:56
[fcrepo4] cbeer created sparql-rdf-type (+1 new commit): http://git.io/0o2ejw
fcrepo4/sparql-rdf-type 61aaed0 Chris Beer: Update admin SPARQL search to support rdf:type assertions about mixins...
* github-ff leaves
<pivotal-bot>Chris Beer added comment: "https://github.com/futures/fcrepo4/compare/sparql-rdf-type?expand=1" https://www.pivotaltracker.com/story/show/60962506
Chris Beer finished "Update administrative search to support rdf:type translations" https://www.pivotaltracker.com/story/show/60962506
* github-ff joins
[fcrepo4] cbeer opened pull request #180: Update admin SPARQL search to support rdf:type assertions about mixins (master...sparql-rdf-type) http://git.io/_7kFaA
* github-ff leaves
<pivotal-bot>Chris Beer estimated "Update administrative search to support rdf:type translations" as 1 point https://www.pivotaltracker.com/story/show/60962506
* ksclarke leaves19:01
* jcoyne leaves19:06
* travis-ci joins19:10
[travis-ci] futures/fcrepo4#1318 (sparql-rdf-type - 61aaed0 : Chris Beer): The build passed.
[travis-ci] Change view : https://github.com/futures/fcrepo4/commit/61aaed08ff20
[travis-ci] Build details : http://travis-ci.org/futures/fcrepo4/builds/14837352
* travis-ci leaves
<bljenkins>Project fcrepo-fixity-corrupter build #519: SUCCESS in 1 min 5 sec: http://ci.fcrepo.org/jenkins/job/fcrepo-fixity-corrupter/519/19:12
Project fcrepo-kitchen-sink build #689: STILL UNSTABLE in 2 min 40 sec: http://ci.fcrepo.org/jenkins/job/fcrepo-kitchen-sink/689/19:15
Project fcrepo-jms-indexer-pluggable build #310: UNSTABLE in 5 min 7 sec: http://ci.fcrepo.org/jenkins/job/fcrepo-jms-indexer-pluggable/310/19:16
* jcoyne joins19:54
* jcoyne leaves19:55
* ksclarke joins20:32
* jcoyne joins20:39
* nbanks joins20:51
* jcoyne leaves21:11
* jcoyne joins21:15
* jcoyne leaves21:31
* jcoyne joins21:39
* jcoyne leaves21:52
* nbanks leaves23:13

Generated by Sualtam