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

Using timezone: Eastern Standard Time
* kaarefc joins03:00
* kaarefc leaves03:32
* kaarefc joins04:07
* fasseg joins06:49
* eddies joins07:50
* kaarefc leaves07:57
* ppound joins08:07
<pivotal-bot>Edwin Shin added "Support the same fcr:versions verb for both object and datastream nodes" https://www.pivotaltracker.com/story/show/4890008708:17
Edwin Shin edited "Support the same fcr:versions verb for both object and datastream nodes" https://www.pivotaltracker.com/story/show/48900087
* eddies leaves08:58
* eddies joins08:59
* eddies leaves
* eddies joins
<pivotal-bot>Vincent Nguyen edited "Create a REST endpoint for dynamically projecting files from a directory from a federated content as datastreams ..." https://www.pivotaltracker.com/story/show/4737377709:35
* kaarefc joins09:44
* eddies leaves10:00
<pivotal-bot>Frank Asseg added "Create an alternative API proposal free" https://www.pivotaltracker.com/story/show/4890869110:13
Frank Asseg edited "Create an alternative API proposal" https://www.pivotaltracker.com/story/show/48908691
Frank Asseg delivered "Create an alternative API proposal" https://www.pivotaltracker.com/story/show/4890869110:14
Chris Beer started "Update Rubydora to use the latest fcrepo4 http APIs" https://www.pivotaltracker.com/story/show/4882472110:15
* kaarefc leaves10:18
* eddies joins10:23
* eddies leaves
* eddies joins
<pivotal-bot>Chris Beer added "[TODO] Proposal to upgrade fcrepo-object-serialization into fcrepo4" https://www.pivotaltracker.com/story/show/4891115310:37
Chris Beer added "[TODO] relationships REST endpoint" https://www.pivotaltracker.com/story/show/4891122910:38
<cbeer>fasseg: did eddies talk about some of barmintor's design goals with his new API? (I assume we didn't document our decisions very well, but...).10:41
* github-ff joins10:42
[fcrepo4] barmintor pushed 1 new commit to master: http://git.io/0R3jxQ
fcrepo4/master e83b481 Benjamin Armintor: unit testing LegacyMethod in fcrepo-jms
* github-ff leaves
* barmintor joins
<fasseg>cbeer: we talked a bit about that, although i dont know what you have in mind particurlaly atm10:45
oh you mean having one reasource/verb for all kinds of objects datastreams and nodes10:46
<cbeer>things like arbitrary jcr paths to "fedora objects", extensibility considerations
<fasseg>well yeah but since those paths contain slashes they are quite unusable for path parameters unless the get urlencoded, therefore i moved this to the nodes sectio n with a path query param...10:47
<cbeer>how to incorporate jcr workspaces
i think barmintor's intention was to expose that hierarchy in the URL itself with some magic globbing
<fasseg>otherwise you get ambiguities, if you're not using some special approach like the fcr namespace for rest versb10:48
<barmintor>indeed, this is how all the resources we refactored in Salem work
fasseg: indeed, we are using the fcr namespace for the verb
(or whatever matching pattern a given jaxrs resource specifies)
<fasseg>yeah i saw that, and it came quite unintuitive to mee since it seemed like a fedora object as in namespace:pid10:49
<barmintor>well, if it makes you feel any better, all the path parts leading up to it could have namespaces, too :)
<fasseg>and frankly i think using query params for a thing like a pth is a valid approach, and it doensn't introduce the need for a special mechanism.
hehe yeah and we can even call it by aname and have someone write a paper about it ;)10:50
so you can do /nodes?path=/node1/child1 or sth with an accept type of application/xml and get a datstream/object/workspace or whatever profile..10:52
or /nodes/content?path=/node/child1 to get the actual binary data
<cbeer>i know we had a discussion about query parameters too. i can't remember why they got rejected, but probably for aesthetics and RESTful purity.10:55
anyway, i'll try to improve the existing doc to incorporate some of the design decisions
and give some usage examples10:56
<fasseg>yeah people dont like query params, but i think in this case they are spot on...
one could alos urlencode the PathParameter but this would get very ugly
<barmintor>fasseg: really? I think this is a poor use case for them, but I've missed part of your discussion.10:57
* travis-ci joins10:59
[travis-ci] futures/fcrepo4#442 (master - e83b481 : Benjamin Armintor): The build passed.
[travis-ci] Change view : https://github.com/futures/fcrepo4/compare/c42bb5cd6cc2...e83b48115e79
[travis-ci] Build details : http://travis-ci.org/futures/fcrepo4/builds/6728973
* travis-ci leaves
<bljenkins>Yippie, build fixed!
Project fcrepo4 build #479: FIXED in 17 min: http://ci.projectblacklight.org/jenkins/job/fcrepo4/479/
armintor: unit testing LegacyMethod in fcrepo-jms
I was hoping that test would put us over 40%
<cbeer>barmintor: i was just trying to figure out how much of our discussion eddies passed along before asking stupid questions about fasseg's doc: https://wiki.duraspace.org/display/FF/Alternative+proposal+for+REST+API
<fasseg>hmmm in my mind a query param is a constraint on a resource, and since a JCR path is not working very well as a PathParameter, the queryparam is the way to go
<cbeer>barmintor: oh, do you know if eddies fixed the kitchen sink?
<eddies>ok party people. standup
cbeer: no
eddies: will you still fix it? should we tell barmintor so he can say "it's obvious!"?
<eddies>cbeer: i didn't have our mode dependency when i was on the plane and didn't get very far
let's tell barmintor and see
<fasseg>hmm if the path is always at the end it should work though11:02
ah no...forget it11:03
<barmintor>I will say, just glancing at it, that the alternative proposal there will only work in FCR3
<fasseg>can you elaborate a bit?11:04
<barmintor>it won't work with multiple levels of hierarchy
it also won't work unless you have object ids and not names
<fasseg>can we talk a bit later, cause I dont see that atm...
because of ambiguities?11:05
you could use names instead of ids, couldn't you?11:06
. /objects/{name} doesn't identify a resource
<fasseg>if the name is uniqe...
or is that the point?
<barmintor>that's not a name, that's an id11:07
"/objects/foo" is unique, because it's a path
but then you need to be able to address the other paths that terminate in "foo"
<fasseg>sry my turn atm in standup..11:08
<eddies>@Path("/rest/{path: .*}/fcr:versions")11:11
<cbeer>eddies: want to let this conversation go on?11:12
<eddies>cbeer: let's let them take it offline11:13
<barmintor>link me an error!11:14
<fasseg>barmintor: in the globbing bracnh i still have FedoraDatatstream resource...should i merge this in from master then?11:15
and all the methods are in there...
<barmintor>fasseg: can you link me the commit?11:16
the globbing branch was merged into master, but I'm not sure if it branched again before
(I can't remember)
<barmintor>thank you
<fasseg>barmintor: if the name is of variable length and contains slashes I would tend to use query params for names as well...11:18
so something like /objects?name=....
<barmintor>fasseg: but the whole point of the name is that it's a path...11:19
re: the Datastreams resource: That is there for batch operations on datastreams
I think the ticket for fixity and versions was to move those methods out of that Datastreams resource into new Versions an Fixity resources11:20
and I think the Fixity move happened in master
fasseg: the fixity move was here https://github.com/futures/fcrepo4/commit/a55d12a0191f97253e1492ba04cd336e4cd302f811:21
<cbeer>barmintor: https://gist.github.com/cbeer/3495026b2ab23dc4bb20
<barmintor>cbeer: thanks
<fasseg>well if you guarantuee that the first verb is always different for different resources you can also append the path as a Path Param as in /nodes/{path} or /node-versions/{path} you can actually use the path w/o ambiguities...11:25
but it would have to be at the end always :/11:26
do no /objects/{path}/versions ...
<barmintor>it is important to remember that "objects" is part of the path now
<fasseg>ok I will first look at master..11:27
<barmintor>b/c federated content might have the same name
(likewise content in different workspaces)
it doesn't realize there's a circular dependency between the fcrepo-legacy-api build and fcrepo4.
eddies: cbeer: jcoyne: sometime soon, i wonder if it'd make sense for fcrepo4 to present our work to hydra. now that we've changed ALL THE THINGS 11:37
jcoyne: yes
<eddies>jcoyne: yes. for my part i'd like to get some of our REST API thought through before we present (i'm hoping the next sprint will do that)11:39
jcoyne: i don't want to present the fcrepo4 api as a fait accompli (b/c i want the feedback and to be able to adjust based on that feedback), but i also don't want to come in as "hey, it's all up for grabs"11:40
<cbeer>eddies: jcoyne isn't in here.
<barmintor>is jcoyne in this room? I can't see him.
<cbeer>that was from #projecthydra
<eddies>i just saw jcoyne quoted
now i realize :P
<bljenkins>Project fcrepo-kitchen-sink build #221: SUCCESS in 2 min 32 sec: http://ci.projectblacklight.org/jenkins/job/fcrepo-kitchen-sink/221/11:42
<pivotal-bot>Chris Beer added "RESTful error codes" https://www.pivotaltracker.com/story/show/4891859511:47
Chris Beer added "HATEAOS responses" https://www.pivotaltracker.com/story/show/4891927111:52
<cbeer>eddies: what was our new fcrepo4 tag line to replace : "That Which I Should Have Done I Did Not Do" ?11:58
<eddies>cbeer: i forget, other than we did come up with a few good candidates last week11:59
anyone see a reason not to have the failsafe and surefire plugins declared in the parent pom?12:03
<cbeer>fcrepo 4: it's in the van.
<eddies>cbeer: but i seem to have the vague memory of actually coming up with some that we said should be the new tag line, whereas the "in the van" was more along the lines of local idiom12:04
<pivotal-bot>Paul Pound added comment: "having issues using the jcr query languages, investigating" https://www.pivotaltracker.com/story/show/4835140112:16
Paul Pound added comment: "currently blocked by ticket 48351401" https://www.pivotaltracker.com/story/show/4825389912:18
Chris Beer added "standardize on a common fcrepo4 prefix for things" https://www.pivotaltracker.com/story/show/4892251312:28
Chris Beer added comment: "updated with grouping and examples." https://www.pivotaltracker.com/story/show/4879946712:38
<cbeer>"mbklein: I'm not sure I like the /rest/ prefix on the API. But I can see where it might feel necessary."12:39
i wonder if there's a better term to use than "rest"
"api" might be better12:40
<barmintor>. /apis/rest/, so that we can also have /apis/soap/...
^^ this is a joke12:41
not even funny.
<pivotal-bot>Highest karma: ajs6f (15), cbeer (10), fasseg (3)
Lowest karma: ------------------------------6271f127ca48 (-2), ---------------------------- (-2), metrics (-4)
* barmintor is still ahead of metrics
<cbeer>@karma barmintor
<pivotal-bot>Karma for barmintor has been increased 3 times and decreased 1 times for a total karma of 2.
<cbeer>@karma eddies12:47
<pivotal-bot>Karma for eddies has been increased 1 times and decreased times for a total karma of 1.
* eddies is confused. i tweaked kitchen-sink to run integration tests, and basically copied over the sanitytestIT from fcrepo-webapp. this appears to start jetty correctly, the test passes, etc. but mvn jetty:run-war fails to start with exactly the error that i was expecting to see12:49
* eddies shakes his fist at maven
* github-ff joins13:06
[fcrepo4] eddies pushed 1 new commit to master: http://git.io/xpKYgQ
fcrepo4/master fe85fc4 Edwin Shin: Explicitly adds surefire and failsafe to build/plugins
* github-ff leaves
* kaarefc joins13:11
<bljenkins>Project fcrepo4 build #482: UNSTABLE in 10 min: http://ci.projectblacklight.org/jenkins/job/fcrepo4/482/13:16
Edwin Shin: Explicitly adds surefire and failsafe to build/plugins
* travis-ci joins13:23
[travis-ci] futures/fcrepo4#443 (master - fe85fc4 : Edwin Shin): The build passed.
[travis-ci] Change view : https://github.com/futures/fcrepo4/compare/e83b48115e79...fe85fc462dd1
[travis-ci] Build details : http://travis-ci.org/futures/fcrepo4/builds/6733013
* travis-ci leaves
<fasseg>barmintor, eddies: now i run into different problems when I trying to put object and datatsream versions into one Resource:13:31
<eddies>cbeer: did you intentionally leave fcrepo-legacy-api as a dependency in fcrepo-webapp? (i.e., when you moved legacy out of fcrepo4, did you mean to have fcrepo-webapp continue to include it)
<fasseg>It works well if you're just requesting a object version say by calling /objects/testobject/fcr:version
<cbeer>yes. i left it out.
kitchen-sink only.
<fasseg>but if you're trying to get a datastream version, say : http://localhost:8080/rest/objects/FedoraDatastreamsTest1/fcr:datastreams/ds1/fcr:versions13:32
<eddies>cbeer: no, it's there as a compile dependency in fcrepo-webapp (master)
<fasseg>jax-rs doesn't know which resource to choose
<eddies>any, i'm going ahead and nuking it
<cbeer>oh. then i unintentionally failed to remove it.
<barmintor>sure it does, but your URI should be /rest/objects/FedoraDatastreamsTest1/ds1/fcr:versions
<fasseg>ah ok...
<barmintor>fasseg: I made some updates to the api proposal about this, but I think what we would be talk about is:13:34
. /rest/objects/FedoraDatastreamsTest1/ds1/fcr:versions
would list the ds versions
<eddies>cbeer: which also means, I think, that fcrepo-webapp was exhibiting the same problem i observed earlier. that the sanity test which starts the webapp in jetty seems to work, even w/ the busted legacy-api module
<barmintor>. /rest/objects/FedoraDatastreamsTest1/ds1/fcr:describe?version=XXX would fetch a particular version of the ds profile13:35
. /rest/objects/FedoraDatastreamsTest1/ds1/fcr:content?version=XXX would get a particular version's content13:36
<eddies>cbeer: i'm getting the following stacktrace on starting kitchen-sink13:41
<fasseg>so a one to one mapping from "fcr:*" to Jax-Rs Resources...13:42
<fasseg>which still seems odd to me, but it should work13:43
<eddies>cbeer: which is because in kitchen-sink we have both the storagePolicyBean in policy_driven_storage.xml (in fcrepo-kitchen-sink) and org.fcrepo.binary.PolicyDecisionPoint in repo.xml (in fcrepo-webapp)13:44
<fasseg>and we are constrained to using one fcr:* verb per request as long as it's not in the same JAX-Rs resource as the first fcr:* part....
* github-ff joins13:46
[fcrepo4] fasseg created globbing-versions (+1 new commit): http://git.io/2fxxIw
fcrepo4/globbing-versions b5f4fe3 fasseg: added version resource and simple integration test
* github-ff leaves
<fasseg>so for a version profile I did it like that: https://github.com/futures/fcrepo4/blob/b5f4fe3cca49bac939c183c6e2e2108d4b04a151/fcrepo-http-api/src/main/java/org/fcrepo/api/FedoraVersions.java13:47
* github-ff joins
[fcrepo4] eddies pushed 1 new commit to master: http://git.io/ocdKRA
fcrepo4/master a2bc6e8 Edwin Shin: Removes fcrepo-legacy-api dependency from fcrepo-webapp
* github-ff leaves
* github-ff joins13:50
[fcrepo-kitchen-sink] eddies pushed 1 new commit to master: http://git.io/lKXUZA
fcrepo-kitchen-sink/master ed697f0 Edwin Shin: Adds integration test support to kitchen sink.
* github-ff leaves
* github-ff joins13:56
[fcrepo4] fasseg pushed 1 new commit to globbing-versions: http://git.io/xJ3M9Q
fcrepo4/globbing-versions 3840e34 fasseg: fixed get ds/obj version
* github-ff leaves
<cbeer>eddies: ping?13:58
<eddies>cbeer: pong
<cbeer>https://gist.github.com/eddies/5483316 is still a problem?13:59
and i'm leaving that to you
<eddies>i believe i've fixed the issue w/ legacy-api now
<cbeer>i think storage policies should be optional in -webapp
and wired into kitchen sink
<eddies>but this is related to storage policies
<cbeer>sound right?
<cbeer>(how to do that in spring remains fuzzy to me.)14:00
* kaarefc leaves
<eddies>i can see the argument, but it seems like we want support for storage policies to be part of fcrepo
<cbeer>yes, support for. but should operate fine without anything defined14:01
<eddies>it's just that a *specific* policy should only be part of kitchen-sink
<cbeer>and push configuration all the way up to the app for now
until we store it in JCR
<eddies>ok, when you get kitchen-sink happy again, you can uncomment legacy-api from the kitchen-sink pom14:02
i left it commented out, just for you to isolate the current failure against the storage policies
* travis-ci joins14:04
[travis-ci] futures/fcrepo4#444 (master - a2bc6e8 : Edwin Shin): The build passed.
[travis-ci] Change view : https://github.com/futures/fcrepo4/compare/fe85fc462dd1...a2bc6e87ca65
[travis-ci] Build details : http://travis-ci.org/futures/fcrepo4/builds/6734145
* travis-ci leaves
<fasseg>barmintor: I couldn't get two fcr:* verbs in one request to run: so this might be a problem: /rest/{path}/fcr:new/fcr:content
<barmintor>it matches the Content resource with best-match. It works- let me find the test...
<bljenkins>Yippie, build fixed!14:13
Project fcrepo4 build #484: FIXED in 13 min: http://ci.projectblacklight.org/jenkins/job/fcrepo4/484/
Edwin Shin: Removes fcrepo-legacy-api dependency from fcrepo-webapp
<fasseg>yea i can debug in there and get to the right point..
<barmintor>fasseg: I had trouble getting multiple verbs with the path broken up by them to work. Orginally we were trying to do /rest/{path}/fcr:datastreams/{dsid}/fcr:content and I couldn't get that to work14:15
but if they're stacked up at the end, you can just have the content resource work it out
<fasseg>yeah that's where i had the probs too since i tried to request .../fcr:datastreams/ds1/fcr:version14:16
<barmintor>fasseg: I spent most of a day trying to get a look-ahead regex to work, I just couldn't do it14:17
it would either match the path as "", or greedily consume the whole rest of the path
this is how we ended up at verbs-on-the-end, trying to support arbitrary hierarchy and still being able to match14:18
<bljenkins>Project fcrepo-kitchen-sink build #222: SUCCESS in 5 min 24 sec: http://ci.projectblacklight.org/jenkins/job/fcrepo-kitchen-sink/222/14:19
<barmintor>on the server side, it's basically like verb-at-the-beginning, but it seemed nicer on the client side to not have to re-build the beginning of the URI
<fasseg>but just append some verbs to a set repo url14:21
i see
ill be away for a bit...diner...14:22
<cbeer>fasseg, barmintor: sorry, i wasn't paying attn, but what's this about fcr:datastreams/ds1/fcr:version?14:27
shouldn't it be rest/path/to/ds1/fcr:version?
<barmintor>cbeer: yes
<cbeer>(and the datastream-ness is implicit)
<barmintor>cbeer: though I was suggesting that the only new resource would be a listing of all the versions, and that getting a particular version would be a query param on the relevant resource (.../fcr:describe or .../fcr:content)14:29
<cbeer>makes sense14:30
* github-ff joins14:42
[fcrepo4] cbeer pushed 1 new commit to master: http://git.io/PmcAbw
fcrepo4/master d2d1751 Chris Beer: make the storagePolicyDecisionPoint an optional bean
* github-ff leaves
* kaarefc joins14:43
<cbeer>eddies: things were failing on jetty:run-war before, right?14:47
<bljenkins>Project fcrepo4 build #485: FAILURE in 5 min 54 sec: http://ci.projectblacklight.org/jenkins/job/fcrepo4/485/
Chris Beer: make the storagePolicyDecisionPoint an optional bean
<cbeer>looks like sonatype is gone14:52
* travis-ci joins14:55
[travis-ci] futures/fcrepo4#445 (master - d2d1751 : Chris Beer): The build passed.
[travis-ci] Change view : https://github.com/futures/fcrepo4/compare/a2bc6e87ca65...d2d1751ac04d
[travis-ci] Build details : http://travis-ci.org/futures/fcrepo4/builds/6735529
* travis-ci leaves
* github-ff joins15:01
[fcrepo-kitchen-sink] cbeer pushed 1 new commit to master: http://git.io/dR-69Q
fcrepo-kitchen-sink/master db94f92 Chris Beer: re-enable legacy api
* github-ff leaves
<cbeer>ok, looks like it might be fixed.15:02
<bljenkins>Project fcrepo4 build #486: NOW UNSTABLE in 9 min 47 sec: http://ci.projectblacklight.org/jenkins/job/fcrepo4/486/15:11
* ppound leaves15:53
<bljenkins>Yippie, build fixed!16:54
Project fcrepo4 build #488: FIXED in 10 min: http://ci.projectblacklight.org/jenkins/job/fcrepo4/488/
Project fcrepo-kitchen-sink build #223: SUCCESS in 3 min 42 sec: http://ci.projectblacklight.org/jenkins/job/fcrepo-kitchen-sink/223/16:59
<pivotal-bot>Chris Beer added "Fix kitchen sink on fcrepo4.fcrepo.org" https://www.pivotaltracker.com/story/show/4895079717:33
Chris Beer started "Fix kitchen sink on fcrepo4.fcrepo.org" https://www.pivotaltracker.com/story/show/48950797
Chris Beer finished "Fix kitchen sink on fcrepo4.fcrepo.org" https://www.pivotaltracker.com/story/show/4895079717:34
Chris Beer delivered "Fix kitchen sink on fcrepo4.fcrepo.org" https://www.pivotaltracker.com/story/show/48950797
Chris Beer delivered "Wire the fcrepo-legacy-api into the kitchen sink, jenkins, etc" https://www.pivotaltracker.com/story/show/4883513317:37
Chris Beer added comment: "http://fcrepo4.fcrepo.org/fcrepo/v3/describe" https://www.pivotaltracker.com/story/show/48835133
Chris Beer added comment: "Assert content is a tiff: ""17:38
$ curl -H "Content-Type: image/tiff" -d @StatusOfResponse-1.png "http://fcrepo4.fcr..." https://www.pivotaltracker.com/story/show/48578951
Chris Beer delivered "Move from fixed hierarchy under /objects to arbitrary hierarchy" https://www.pivotaltracker.com/story/show/48578223
Chris Beer added comment: "Actually, I take that back. I think it'd be better if the whole connection string was parameterized (so, e.g...." https://www.pivotaltracker.com/story/show/4877532717:39
Chris Beer started "Parameterize the OpenWire port used by ActiveMQ" https://www.pivotaltracker.com/story/show/48775327
Chris Beer accepted "FedoraNamespaces should be re-mapped and integration tested" https://www.pivotaltracker.com/story/show/48799771
Chris Beer added comment: "https://github.com/futures/fcrepo4/commit/66cd2184814dbabd838f7e37b5e503a3d4ba4bc7" https://www.pivotaltracker.com/story/show/4877532717:46
Chris Beer delivered "Parameterize the OpenWire port used by ActiveMQ" https://www.pivotaltracker.com/story/show/48775327
* github-ff joins
[fcrepo4] cbeer pushed 1 new commit to master: http://git.io/x0jS-g
fcrepo4/master 66cd218 Chris Beer: parameterized the whole activemq connection string
* github-ff leaves
<bljenkins>Project fcrepo4 build #489: UNSTABLE in 8 min 51 sec: http://ci.projectblacklight.org/jenkins/job/fcrepo4/489/17:55
Chris Beer: parameterized the whole activemq connection string
* fasseg leaves18:03
* travis-ci joins
[travis-ci] futures/fcrepo4#446 (master - 66cd218 : Chris Beer): The build passed.
[travis-ci] Change view : https://github.com/futures/fcrepo4/compare/d2d1751ac04d...66cd2184814d
[travis-ci] Build details : http://travis-ci.org/futures/fcrepo4/builds/6740862
* travis-ci leaves
<pivotal-bot>Chris Beer added "Add POST /fcr:new request" https://www.pivotaltracker.com/story/show/4895418118:18
* kaarefc leaves18:52
* eddies leaves20:14
* eddies joins
* eddies leaves
* eddies joins
* barmintor leaves21:09