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

Using timezone: Eastern Standard Time
* nbanks joins01:10
* nbanks leaves01:15
<bljenkins>Project fcrepo-kitchen-sink build #236: FAILURE in 1 hr 31 min: http://ci.projectblacklight.org/jenkins/job/fcrepo-kitchen-sink/236/
* kaarefc joins01:26
* kaarefc leaves01:48
* kaarefc joins02:22
* kaarefc leaves02:42
* eddies leaves02:54
* eddies joins03:27
* eddies leaves
* eddies joins
<pivotal-bot>Edwin Shin added comment: "See: https://docs.google.com/a/yourmediashelf.com/document/d/1ZzSSOQZ7HSyPjw3b8gjOUvIrpdchJAR6b4oW3TwFLQc/edit" https://www.pivotaltracker.com/story/show/4906084503:51
Edwin Shin added comment: "And as an HTTP alternative to SPARQL Update: http://www.w3.org/TR/sparql11-http-rdf-update/" https://www.pivotaltracker.com/story/show/49060845
Edwin Shin added comment: "And for historical reference, this fcrepo3 discussion: https://wiki.duraspace.org/display/FCREPO/Supporting+t..." https://www.pivotaltracker.com/story/show/4906084504:02
* kaarefc joins04:04
* kaarefc leaves
* fasseg joins04:23
eddies: shall I merge, or rather rebase, the changes from the globbing versions branch onto master?04:29
so the extra version resource
or shall we talk a bit more about versioning?
<eddies>i'd rebase your branch and submit a pull request04:30
<fasseg>okay I'll do that, when im finished...04:32
* eddies leaves05:08
* eddies joins05:19
* eddies leaves
* eddies joins
<fasseg>eddies: https://wiki.duraspace.org/display/FF/Transaction+enabled+REST+API05:49
Ill have to talk to adam again though, hoping that i captured our ideas from yesterday correctly ;)
<pivotal-bot>Frank Asseg started "Transactions-enabled API" https://www.pivotaltracker.com/story/show/4900920905:50
Frank Asseg added comment: "Added this page: https://wiki.duraspace.org/display/FF/Transaction+enabled+REST+API" https://www.pivotaltracker.com/story/show/49009209
<eddies>fasseg: should obtaining a new transaction resource be implemented as a GET?05:51
<pivotal-bot>Frank Asseg added comment: "Works nice, but maybe we should add the injected values to the HttpServletContext instead of creating N argu..." https://www.pivotaltracker.com/story/show/4906578305:52
<fasseg>you mean beacuase of idempoteency?
<eddies>exactly
<fasseg>lemme dig up the link....
<eddies>fasseg: did you consider providing the transactionid in a header rather than as part of the request uri (i'm not necessarily advocating we use headers, just want to know what, if anything, you and/or adam thought about it)05:54
<fasseg>http://stackoverflow.com/questions/9234363/rest-search-interface-and-the-idempotency-of-get05:55
yes but no!
Im very much oppsed to adding stuff to the header which determine the outcome of a request other than accept
<eddies>fasseg: but I think a search request is different than getting a transaction id
getting a transaction id *does* have a side effect
it's like getNextPid05:56
<fasseg>yeah but the point is idempotency doesnt mean you get the same resource everytime, it just means you can safely call the get method arbitrary times without changing state
<eddies>repeated searches may return different results at different times, but it's not due to the search request itself
but GET /fcr:tx causes you to mint a new transaction, right?
<fasseg>yes, everytime...05:57
<eddies>that said, it still feels more natural to me to use a GET to, well, get a transaction id =)
<fasseg>im my mind idempotency is broken when you call get first and that determines the answer of the next get call05:58
but these are completely unrelated in our case..
so there is no state associated with the get
but i guess that's a point open to discussion...05:59
i should rellay read the thesis again now that i understand propably more of it
the problem with adding stuff to the header IMHO is btw, that you complicate client development06:02
and if everthing is part of the URI it's very much more intuitive06:03
id even rather use query params than header fields
<eddies>fasseg: i get that. but shoving it into the request uri feels messy too06:05
(either as part of the path or as a query param)06:06
the transactionid feels like a session identifier, so just like cookies, i can see arguing it should be implemented as an http header
<fasseg>hmm you saw that this is only necessary if the user actually wants to use trasnactions, otherwise he just leaves it out...06:07
<eddies>(or it's like an auth token which you would supply as a header, too)
<fasseg>and if he *wants* to use tansactions the id is a good fit for a path param IMHO
auth token? state? i thought we dont do that...06:08
do we have sessions or sth?
<eddies>no, i'm just trying to draw out parallels06:09
<fasseg>ah ok
yeah I would ever prefere to add the token as a URI param there as well
sth like token=LAHDLJAHD)=§06:10
* kaarefc joins06:12
<fasseg>grml all the web bloggers define idempotency as the result should not change, but that's complete BS, since every search request would not be idempotent e.g.
* kaarefc leaves
<eddies>no, that's the same distinction we made above
<fasseg>and it's not even in the thesis...
<eddies>it's not that GETs have to return the same result every time06:13
<fasseg>exaclty
<eddies>it's that GETs shouldn't create side effects
<fasseg>but that's what all the "professionals" are saying
but that's not very well defined as well...
a search creates load and a search tree in the service which is different every time, but still it's considered safe...06:14
although it has "some" side effects
there could even be diff services active for different searches06:15
so as long as you're not serving static content you always have some kind of internal state associated with a request
and what about something like GET /rest/randomnumber which just returns a random int?06:17
<eddies>that's fine
that's just like the example in the SO link, where you GET /currentTime or GET /weather06:18
<fasseg>the previous get has no side effects on the next call, same as in our case, just our random number generator generates transaction ids
<eddies>hmm…i can buy that
i think for limiting the life of transactions, what do you think about using the expires header in the reponse?06:22
and have you given any thought to locking?06:23
<fasseg>yes expires is abloutely ok06:24
IMHO
the lokcing we thought about was a checkout mechanism from a distributed hahmap
so that when a request associated with a transaction arrives, the thread removes the transaction from the hashmap into a threadlocal06:25
so we can guarantuee that only one request is manipulating a tx at one time06:26
but this introduecs a limitation that no concurrent request on the same transaction can be made
which is kind of nice, adam nad I thought because it forces the user to adhere to a sequential transaction workflow
but this of course would have to be tested ;)06:27
since yeah you know concurrency is hard they say..06:28
<eddies>especially since this also has to cope with running against a cluster
i'm not really sure how that's going to work
<fasseg>that's where the checkout mechanism comes in:06:29
1) create transaction -> the repo creates a new trasnaction puts it onto a distributed hashmap and returns the id
<eddies>ah06:30
i missed when you said the distrib hashmap earlier
<fasseg>2) the user creates a new object -> the request thread removes the tx from the distributed hashmap onto a thread local and manipulates it, after that it puts it back onto the hashmap
ah ok
I tried this with hazelcast once in a HDFS environment, and it worked nicely06:31
and auite fast too
*quite
<eddies>ok, i think i'm getting my head around why i'm uncomfortable with the txid as a path param:06:32
<fasseg>and for us it would look as if it's "lock-free"
<eddies>given that /rest/objects/mypid:1/DC is my dc datastream resource06:33
then the HTTP verbs applied to /rest/objects/mypid:1/DC/fcr:tx/1234 seems wrong06:35
<fasseg>true is not a very descriptive uri06:36
<eddies>because i'm really talking about operations on the datastream resource, no?
<fasseg>idd
<eddies>well, anyway. i really like the document you put together06:37
<fasseg>hmm but this is ok IMHO: /rest/objects/mypid:1/DC/?tx=1234
<eddies>it makes having a concrete discussion about a transactions rest api much easier
fasseg: yes, except PUT and POST w/ a query param seems to be frowned upon06:38
<fasseg>yep just look at the last 50 minutes of chat ;)
<eddies>then again, i don't need to be religious about being RESTful either
wow. time flies when you're having fun ;-)06:39
actually, i have to step out for a bit
<fasseg>I would switch a header field with implementation sepcific semantics everyday for a query param...
kk
<eddies>can i ask you to post the wiki page you wrote up to ff-tech
<fasseg>lemme just talk a bit to adam first and add some corrections and comments possibly...
<eddies>ok06:40
ttyl
<fasseg>eddies: Hmm but i guess when were thinking of a transaction as a resource accessible by the user we should relly be using post, since a new resource is actually created....06:43
changed to POST :)06:44
and what about if we push the tx: variable to the front? A URI of /rest/fcr:tx/1234/objects/mypid:1/DC makes more sense doesn't it? since it actually wraps the resource call...06:45
so it says in the transaction 1234 update mypid:1's DC datastream06:51
<pivotal-bot>A. "Reticulated" Soroka added comment: "Depends on which is more testable. Long method signatures aren't good in themselves, but neither..." https://www.pivotaltracker.com/story/show/4906578307:39
* nbanks joins08:10
* kaarefc joins08:36
* kaarefc leaves08:55
* kaarefc joins09:00
* nbanks_ joins09:07
* nbanks leaves
* kaarefc leaves09:14
* barmintor joins10:21
* ajs6f joins10:30
fasseg: I thought we _were_ going to put the txaction id towards the front of the URL, and hang a copy of the rest of the API off the end…?10:31
afk bbs
<cbeer>i agree with ajs6f -- i thought we were putting the txid towards the front so we can use the same globbing mechanics to deal with it10:33
and i missed a lot of the discussion, but starting a new tx should be a POST because it should generate the txt path and return it as the 201 Created location, no?10:34
eddies: the http rdf update api isn't clicking with me this morning..10:35
fasseg: or, i see this example in the tx doc: POST /rest/fcr:tx/{transaction-id}/{path}/fcr:datastreams/10:39
why not:
POST /rest/{tx:id/path}/fcr:datastreams/
also: "The idea is to use a distributed HashMap as a collection of open transactions and have actors check -out/-in transactions from/to the HashMap."10:40
doesn't jcr or modeshape have locking notion?
i really wish confluence was (any good at all) for collaborating on a doc10:42
<barmintor>why not: POST /rest/fcr:tx -> Location: /rest/fcr:tx/{txid}10:43
POST /rest/{path}/fcr:whatever?txid={txid}
PUT /rest/fcr:tx/{txid}/close10:44
or commit, or w/e
and ideally, GET /rest/fcr:tx/{txid} -> list of the uncommited ops
also confluence--10:45
<ajs6f>So one question is whether xactions are first class entities. IOW, do we expect to provide any endpoints specific to them besides create, commit, and rollback? If so, then we ought to use POST/201. If not, we can make other decisions. (Like redirecting or some other approach.)10:49
* kaarefc joins10:56
<barmintor>the other thing we could do is just have /rest/fcr:transactions, and let it accept serializations of a series of operations, which it performs and commits as a single step10:57
well, not *the* other thing, but *another* thing10:58
<ajs6f>barmintor: Yeah, but the thing I don't like so much about that is that it requires us to maintain a serialization form for operations.11:01
I'd rather just reuse the API.
We do have experience with such a serialization from fcrepo3.11:02
For the batch utilities.
<eddies>cbeer, barmintor fasseg: it's hangout time
<cbeer>noooo
<eddies>well, i guess barmintor is excused
<ajs6f>FUN AND GAMES FOR EVERY GIRL AND BOY! HANGOUT TIME!11:03
* kaarefc leaves11:06
<barmintor>RISE TO THE EXECRATION, AJS6F!11:07
<ajs6f>Execrate the risible?
<barmintor>BOTH!
<ajs6f>I'm going to be covered in mud after Charlottetown.
+1 to minimal mocking.11:11
<barmintor>Who mocks Mockito?11:12
<ajs6f>Powermock.
<barmintor>ajs6f, eddies: One Powermock feature that does generally interfere with instrumentation is mocking constructors11:13
<cbeer>http://www.w3.org/TR/sparql11-http-rdf-update/11:16
http://www.pivotaltracker.com/story/show/49060845
<pivotal-bot>feature: Propose a straw-man relationship management API (unstarted) / owner: A. "Reticulated" Soroka
<cbeer> https://docs.google.com/a/yourmediashelf.com/document/d/1ZzSSOQZ7HSyPjw3b8gjOUvIrpdchJAR6b4oW3TwFLQc/edit
<pivotal-bot>Frank Asseg delivered "Copy node from federated filesystem to Infinispan cache" https://www.pivotaltracker.com/story/show/4825242311:28
Frank Asseg started "Could we use JAX-RS context to inject an authenticated session" https://www.pivotaltracker.com/story/show/4906578311:29
Frank Asseg accepted "Could we use JAX-RS context to inject an authenticated session" https://www.pivotaltracker.com/story/show/49065783
<cbeer>i'd rather have that discussion next week, personally.
<pivotal-bot>A. "Reticulated" Soroka added comment: "https://github.com/futures/fcrepo4/tree/ProviderForSession" https://www.pivotaltracker.com/story/show/49065783
<barmintor>You know why you hear that ajs6f? Because everything on he project is strongly typed!11:30
<ajs6f>Eh? Hear what? Wait, let me put my ear trumpet in, sonny.
<nbanks_>Is there any plan to auto ingest the default fedora object's that were present in fcrepo3 like "fedora-system:ContentModel-3.0" ?11:33
<cbeer>i don't know why we would11:34
<nbanks_>Islandora expects it to exist, there will be objects in existing repositories that declare hasModel relationships with it.11:35
<nbanks>Is there any reason why we wouldn't?11:37
<cbeer>we don't have any notion of content models, sdefs, or any of that11:38
* github-ff joins11:39
[fcrepo4] cbeer pushed 2 new commits to master: http://git.io/CmHmKw
fcrepo4/master cf51c20 Chris Beer: change setContent signature back to take an input stream, but pass the storage policy point into the Datastream
fcrepo4/master ce3bc7e Chris Beer: add example of policy-driven storage IT
* github-ff leaves
<nbanks>I could see getting rid of sdefs, but no content models? How do you defines types of data?
<cbeer>we haven't said anything about modeling11:40
<nbanks>so its future discussion then? I'll see if I can work around this in the meanwhile.
<cbeer>why does islandora expect them?11:41
<nbanks>We use Content Models pretty extensively, all of our "solution packs" are build around a type of content, we define our views based on the type of content etc.11:42
Query's filter on type etc.11:43
<cbeer>right, sure.. but why is the object "fedora-system:ContentModel-3.0" important?
<nbanks>? All of our content models are defined as being content models11:44
<pivotal-bot>Frank Asseg added "Inject athenticated sessions into the JAX-RS resources" https://www.pivotaltracker.com/story/show/49205649
Frank Asseg edited "Inject authenticated sessions into the JAX-RS resources" https://www.pivotaltracker.com/story/show/49205649
<nbanks>In several pages we list all the "types" as defined as things that have a hasModel relationship with "fedora-system:ContentModel-3.0"11:45
So when I want to associate a metadata form with a given type, I list all the types to the user they can make an association with, and limit what datastreams they could associate the metadata form with based on the DC-COMPOSITE-MODEL datastream.11:46
* travis-ci joins11:48
[travis-ci] futures/fcrepo4#464 (master - ce3bc7e : Chris Beer): The build has errored.
[travis-ci] Change view : https://github.com/futures/fcrepo4/compare/e709a875f154...ce3bc7ebaff7
[travis-ci] Build details : http://travis-ci.org/futures/fcrepo4/builds/6856327
* travis-ci leaves
<nbanks>How do we define "types" of objects now?
<barmintor>nbanks: mixins
nbanks: you can still have "type" metadata, either in the form of nodeType/mixin metadata or a named object property11:50
which is basically what CModels are, anyway
nbanks: did that make any sense?
<nbanks>thanks, its enough to set me in the right direction, this is the latest docs for ModeShape? http://www.jboss.org/modeshape/docs/release3-2-0-final11:52
So to set the type of of a object, will I need to wait for the relationships endpoint to be further refined?11:54
Using the relationships end point I would set the objects property jcr:mixin? with the jcr:primaryType would be fedora:object?11:55
<barmintor>Hilariously, Roy Fielding uses txid as a header: http://www.infoq.com/news/2009/06/rest-ts11:56
(or originally did)
ajs6f: I'm glad one of us does11:57
<ajs6f>barmintor: Which one?11:58
<bljenkins>Yippie, build fixed!12:04
Project fcrepo-kitchen-sink build #237: FIXED in 5 min 59 sec: http://ci.projectblacklight.org/jenkins/job/fcrepo-kitchen-sink/237/
<cbeer>ajs6f: i think Node.merge is workspace aware.. and implies copying the whole tree, right?12:05
<ajs6f>Yes, and what's more, it only works on versionable nodes.
<barmintor>I wonder if that's the case for update as well12:06
GO FOR GOLD!
TAKE IT ALL THE WAY!
<ajs6f>Yet another metaphor. The man is a factory!
<cbeer>fasseg: you're done working on the fcr:versions branch right? i'll take a look at it (make sure it'll work with hydra, at least) and merge into master
<fasseg>well not a 100%..there still the need for a test with a version mixin, so let me work on it until monday evening, then it'll be ready for the *rebase*12:07
<ajs6f>So, eddies, the scope includes named graphs, inferencing with OWL Full support, and LD harvesting, right?12:08
<pivotal-bot>A. "Reticulated" Soroka estimated "Inject authenticated sessions into the JAX-RS resources" as 5 points https://www.pivotaltracker.com/story/show/4920564912:10
<eddies>ajs6f: right, and i need you to implement that by wednesday
<cbeer>oh, and it needs to be highly performant12:11
sub-ms response times, at least.
<eddies>so, I mint a new transaction resource: /rest/tx:12312:12
behind the scenes we're creating a new workspace with id tx:123
<cbeer>well, no. you don't mint the resource. fcr tells you where to find the resource it creates
<eddies>ok. i have a transaction resource, tx:12312:13
<ajs6f>OWL Full is built for speed.
<eddies>provided to me by the generous fcrepo gods
<ajs6f>Actually, there's an interaction here (i.e. the relationship stuff) with what we've already got:
cbeer has several times pointed out that w'd like the describe endpoints to be able to return an RDF rep.12:14
<eddies>now, i can make all my normal api requests just prefixed by /tx:123?
<ajs6f>I agree %100. What's more we'd like these URLs to be LD-friendly.
So we may have to think about how info in a named graph gets
<cbeer>eddies: yes
<ajs6f>integrated with whatever is being done at the descirbe endpoints.
If you DELETE to /tx:123, you rollback the xaction.12:15
<eddies>so, if i have a datastream, /mypid:123/DC
and i want to say, delete it12:16
<cbeer>DELETE /tx:123/mypid:123/DC
<eddies>there's something weird about DELETEing /tx:!23/mypid:123/DC
<cbeer>why? you're deleting mypid:123/DC in the scope of your tx
you're not deleting everyone's mypid:123/DC12:17
<ajs6f>Cause /tx:!23/mypid:123/DC is a subresource of /tx:!23/
SO /mypid:123/DC is somethig else.
Even tho' they have an obvious connection.
<eddies>ok, this is what i was getting at…are we really saying these are all subresources of tx:123?12:18
sometimes it seems like i'm talking about POSTing a api request to the transaction resource12:19
<ajs6f>If we clone them from the default workspace, they literally are different resources.
<eddies>as in, the thing i'm doing to the transactions resource is creating a series of API requests
right. but that also means i can just navigate the entire repository from /tx:123, right?12:20
<barmintor>eddies: this is why I prefer the branch analogy
(and yes)
<eddies>barmintor: yeah
i think i've come round to that12:21
<cbeer>because real transactions over HTTP is both silly and hard.
<barmintor>cbeer++
<cbeer>or, rather, inherently non-restful
<barmintor>cbeer++
<ajs6f>Transactions are fundamentally operation-oriented.12:23
REST is resource-oriented.
ItLike mixing milk and grape juice.
<barmintor>ajs6f: http://www.imponderables.com/archives/000585.php12:29
<ajs6f>Grape: the offical ice cream flavor of Fedora 4.12:30
<pivotal-bot>Chris Beer added "add an HTML representation of " https://www.pivotaltracker.com/story/show/4921105912:45
Chris Beer edited "add an HTML representation for ObjectProfile" https://www.pivotaltracker.com/story/show/49211059
<ajs6f>Are we supposed to be doing anything to set up a hacfest at OR?12:46
I feel like we meant to do something with that.
<cbeer>i think eddies said he'd like to be the sole organizer for that, and that we don't have to do anything12:51
maybe not even show up
control freak.
<eddies>careful. i'm going to practice delegation and have one of you experience the, umm, pleasure of doing all the logistics12:53
<cbeer>think of how many more waking hours you have than the rest of us!12:54
true dedication to the project
<ajs6f>I hung out as a judge in Ediburgh. It was kind of fun. But after a few days, the devs really start to smell funy.12:57
I'm really looking forward to this:12:58
http://or2013.net/content/building-fedora-futures
I'm really excited to hear about all the new great stuff in Fedora 4.
<pivotal-bot>Chris Beer added comment: "got CRUD working, but now blocked by implementations for:12:59
- updating obj/ds properties
- versioning suppo..." https://www.pivotaltracker.com/story/show/48824721
<cbeer>ajs6f: so, we're doing something different than what's in https://github.com/futures/fcrepo4/tree/ProviderForSession?13:00
<ajs6f>SIlghtly. I injected into method signatures there, and barmintor pointed out that it would be better to inject into fields.
But the provider looks the same.
<barmintor>just to keep from touching all the method sigs13:01
<ajs6f>And fields have 30 percent fewer calories.
<barmintor>return of te Lite API!
<cbeer>ajs6f: ok. i'm just looking for some tickets to take. maybe i'll fiddle with the SPARQL/UPDATE stuff myself13:02
<ajs6f>Or you can go to JMS for the sugar-free API>
cbeer: if the injection ticket is clear to you,
go for it.
<cbeer>it isn't.
<ajs6f>Then don't.
DONE!
<cbeer>good :)
<barmintor>wait, we don't have to do things that aren't clear to us any more?13:04
* barmintor deletes his repo
DONE!
<ajs6f>That's why I take only SemWeb tickets now.
"The only band that matters."
cbeer: You've said a few times that you'd like to see RDF serialization at describe endpoints (which I agre with)...13:16
WOuld you buy the following principle:
All properties of a Fedora object should be serializable as an RDF graph, including13:17
the relationships to datastreams (treated as indpednet resources with identifiers of their own), but not
including the actual bitsreams.
?
'Cause I'm starting to think that the abovedescribed grpah is what eddies commissioned me to dev an API for.13:18
{strawman API}
afk bbl13:21
<cbeer>yes.13:30
* github-ff joins13:31
[fcrepo4] barmintor pushed 1 new commit to master: http://git.io/_dCmxg
fcrepo4/master 8c69156 Benjamin Armintor: Do not Powermock the class being tested
* github-ff leaves
<cbeer>which essentially means, i guess, we have some set of 'special' predicates that may:
- get serialized into jcr:properties (because they match some white-list, i guess?)
- modify the object's relationship with datastreams13:32
- or just get persisted in some well-known location
* nbanks_ joins13:42
* nbanks leaves13:43
<bljenkins>Project fcrepo-kitchen-sink build #238: SUCCESS in 5 min 49 sec: http://ci.projectblacklight.org/jenkins/job/fcrepo-kitchen-sink/238/13:50
* travis-ci joins13:53
[travis-ci] futures/fcrepo4#465 (master - 8c69156 : Benjamin Armintor): The build passed.
[travis-ci] Change view : https://github.com/futures/fcrepo4/compare/ce3bc7ebaff7...8c691569081d
[travis-ci] Build details : http://travis-ci.org/futures/fcrepo4/builds/6859847
* travis-ci leaves
<ajs6f>I'm gone for the weekend. Have fun, all.14:05
* ajs6f leaves
<cbeer>barmintor: ping?14:37
i'm trying to figure out what ajs6f means by jaxrs entity providers and how that's supposed to work with conneg14:38
and jaxb
<pivotal-bot>Chris Beer estimated "REST API getChildren Doesn't respect Accept headers" as 1 point https://www.pivotaltracker.com/story/show/4881802914:52
Chris Beer started "REST API getChildren Doesn't respect Accept headers" https://www.pivotaltracker.com/story/show/48818029
* nbanks_ leaves15:02
* nbanks joins15:03
<pivotal-bot>Chris Beer unstarted "REST API getChildren Doesn't respect Accept headers" https://www.pivotaltracker.com/story/show/4881802915:07
* nbanks leaves15:47
* kaarefc joins15:49
<barmintor>cbeer: do I still have anything to offer you?15:51
* nbanks joins16:15
* kaarefc leaves
<cbeer>barmintor: i guess not. i've given up and can just wait for ajs6f. i don't understand jaxb, or jax-rs, etc, etc.16:18
and building reasonable looking responses with jaxb kinda sucks.
<barmintor>that is true16:19
it's really not for human eyes
and more for round-tripping java obj
<cbeer>yeah. makes me think we'll also want to roll-out-own json serialization
:/16:20
but, whatever. i'm going back to thinking about the object relationships.
and then calling it a day
* nbanks leaves16:34
* github-ff joins17:43
[fcrepo4] cbeer created rdf-all-the-things (+1 new commit): http://git.io/GZpbWA
fcrepo4/rdf-all-the-things 89e0e3d Chris Beer: poke object graph through the REST API
* github-ff leaves
* github-ff joins17:44
[fcrepo4] cbeer opened pull request #54: poke object graph through the REST API (master...rdf-all-the-things) http://git.io/xn_e0A
* github-ff leaves
<cbeer>now to actually make it compile..17:47
* github-ff joins17:54
[fcrepo4] cbeer force-pushed rdf-all-the-things from 89e0e3d to 4231b71: http://git.io/cMpL6w
fcrepo4/rdf-all-the-things 4231b71 Chris Beer: poke object graph through the REST API
* github-ff leaves
<bljenkins>Project fcrepo-kitchen-sink build #239: SUCCESS in 4 min 15 sec: http://ci.projectblacklight.org/jenkins/job/fcrepo-kitchen-sink/239/17:58
Project fcrepo4 build #523: UNSTABLE in 11 min: http://ci.projectblacklight.org/jenkins/job/fcrepo4/523/18:06
* barmintor leaves18:57
* fasseg leaves19:01
* nbanks joins19:15
* nbanks leaves19:19
* eddies leaves21:26
* nbanks joins22:16
* nbanks leaves22:21
* awoods joins22:50
* awoods leaves
* awoods__ joins22:51