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

Using timezone: Eastern Standard Time
* jgpawletko leaves02:14
* escowles_ joins02:30
* escowles leaves02:31
* jgpawletko joins03:20
* dwilcox joins06:50
* dwilcox leaves06:53
* dwilcox joins07:57
* dwilcox leaves
* dwilcox joins
* dhlamb joins08:42
* diegopino joins08:53
* acoburn joins09:05
* whikloj joins09:15
<diegopino>acoburn: good morning. I have been working last night on some ideas and wanted to ask (pretty silly because it's basically in the f4 code)09:25
<acoburn>diegopino: ask away!
<diegopino>in the eventTypes that fedora4 publishesh i see 509:26
there are here https://wiki.duraspace.org/display/FEDORA4x/Setup+Camel+Message+Integrations
and here https://github.com/fcrepo4/fcrepo4/blob/17b158505c84ab85453506ca6fe2c72101476d98/fcrepo-kernel-api/src/main/java/org/fcrepo/kernel/api/observer/EventType.java
I can't find the links provided in the first url in the ontology09:27
<acoburn>That's because they are not there (!)
<diegopino>but anyway, since they are JCR 2.0 based
<acoburn>Yes, but they shouldn't be JCR-based IMO09:28
<diegopino>is there a chance we could get an eventype (i could try to code it.) when a TX is commited
not the individual events, but the whole transaction
<acoburn>you know that no events are emitted until the tx is commited?09:29
<diegopino>Yeah, i know that
<acoburn>so the presence of an event is itself indication that the tx was committed09:30
if the tx gets rolled back, the events are never emitted
<diegopino>I would like just to have a "TX done" or something, with the TX id, i don't want to accumulate each event and check if they belonged to a certain TX.
<acoburn>diegopino: I think that would be very problematic09:31
the reason I say that is that the tx exists only in the context of a single client. it's not global
but the event stream is about the global state of the repo09:32
and you can't (or shouldn't IMO) mix session and global state
do you have a particular use case?
because this may very well be handled in a middleware layer09:33
<diegopino>acoburn: ok, i do have a WIP use case, i'm doing some test and yes, handling this now in the middlelayer and get around with this that way is Ok i think09:34
acoburn: when you say TX is local (session), means i can't use the same TX from a different client? lets say continue adding into an existing TX?09:36
acoburn: i will read the code better
<acoburn>diegopino: REST is stateless, so if you have clients A and B and they have some way to share a tx id, then yes, they could share access to that session
by "client" I mean an HTTP client request with a given TX id, so there's nothing stopping you from having lots of clients using the same TX id09:37
…but if you do that, you're sort of playing with fire09:38
<diegopino>acoburn: Ok, not if i can coordinate sessions.
<acoburn>e.g. what if client A fails? does client B know about that
yes, if you're handling distributed coordination in some other layer, then yes
i.e. via actors or smth like zookeeper09:39
<diegopino>not if i can't have a message event that says TX finished...
zookeeper…you rad my mind
read
<acoburn>zk is pretty awesome, but there can be quite a learning curve
<diegopino>acoburn: pretty used to it already in the solr world09:40
acoburn: but not tied to it
<ruebot>http://www.redbiodiversidad.cl/ is all zoo keeper, right?
...w/r/t solr09:41
<diegopino>ruebot++
5 zookeepers
<acoburn>diegopino: I think zk would be a great fit for API-X and dynamic service discovery — ephemeral znodes for service instances, etc
<ruebot>acoburn++09:42
<diegopino>acoburn: yes, and also i have to read more on API-X
<acoburn>diegopino: I have a working impl (where _working_ involves a little hand-waving)09:43
diegopino: more of a proof of concept
diegopino: ~ 100 lines of code with camel and OSGi
<diegopino>acoburn: i think i will have to move my office to your github =)09:44
<acoburn>diegopino: it's the acrepo-apix module in https://gitlab.amherst.edu/acdc/repository-extension-services/
<diegopino>does acrepo-idiomatic do a full URI rewrite? we get subjects and objects?09:47
<acoburn>diegopino: the idea there is that fedora identifiers are long and ugly: /a/b/c/d/e/blah-blah-blah/more/long/stuff09:48
and I want public identifiers to be short and sweet: /lkasdfj
so, I decouple the fedora identifier from the public (web) URL09:49
<diegopino>acoburn: ah, similar to what we do on claw in microservices, but i mean, you also do this in the rdf response?
acrepo-xml-metadata is going to be loved by librarians
<acoburn>diegopino: I'm not rewriting the fedora URIs with this at all, simply creating a bi-directional mapping between internal <-> external URIs09:50
<diegopino>acoburn: Ok, i will keep experimenting with my stuff. My use case is/was i have a type of repo where "metadata" stays almost the same, but the relations between resources is changing constantly09:51
research data with complex ontologies
and i don't want people to get stuck updating the same group of resources at the same time in different competing TX. So i wanted to do some coordinating, not on frontend but in middleware09:52
acoburn: but i think i have a way of doing it...09:53
acoburn: thanks a lot for the chat
<acoburn>diegopino: it is always a pleasure09:54
<diegopino>acoburn: the pleasure is mine.09:55
* ksclarke leaves10:17
* dwilcox leaves10:27
* peichman joins10:29
* ajs6f joins10:43
ANyone in the mood for a tech meeting? I made a page, but I forgot to send out the invite for items.10:50
<whikloj>ajs6f: Sure, we can rehash the Poison vs Warrant covers debate10:52
ajs6f: diegopino and acoburn were discussing whether F4 could output a tx done event (above). I was debating it with diegopino as well, but know I am wondering would it be horrible to emit an event along with the committed transactions? It would make distributed concurrency much easier to manage10:54
<ruebot>ajs6f: https://wiki.duraspace.org/display/FF/2016-01-28+-+Fedora+Tech+Meeting -- that the same agenda from last week?
<ajs6f>ruebot: Yep. Sue me.
<diegopino>ajs6f: i will be joining, not speaking much today, but who knows =)10:55
<ruebot>should we add that discussion, and the hot thread on the mailing list to the agenda?10:56
then call it a day?
<ajs6f>whikloj: Do you want to talk about that on the call?
ruebot: which discussion?
<whikloj>ajs6f: ruebot mean the ld+json one10:57
<ruebot>ajs6f: the discussion diegopino, acoburn, and whikloj were having, and then the "Body not JSON-LD as requested" thread
<ajs6f>escowles_: Do you want to talk about transactions at all? The islandora guys had a meeting to discuss their use cases and we could talk about that a bit. But maybe it's not worth it.
ruebot: That's find with me. The LD-JSON thigns seems to be getting sorted out on list.10:58
ruebot:whikloj: Events fo transaction end is a little richer.
ruebot: Want to slice and dice the agenda?
<ruebot>ajs6f: yeah, you're right. i just caught the two most recent messages and it looks good to me.
<ajs6f>DAMN THIS FREECONFCALLHD HOLD MUSIC IS FUNCKY.
<whikloj>ajs6f/ruebot: I could also use someone with versioning knowledge to have a look at FCREPO-1830, I poked mikeAtUVa but have not heard from him yet.
<ruebot>ajs6f: sure
<ajs6f>ruebot++10:59
* yinlin joins11:00
* bseeger joins
<ruebot>https://wiki.duraspace.org/display/FF/2016-01-28+-+Fedora+Tech+Meeting11:01
* dwilcox joins
* ajs6f is here.
<bseeger>* is here *
<rarian>Calling in now.11:02
<bseeger>fwiw, I could not direct dial in via my phone (which I usually do)
<ajs6f>rarian++11:03
<whikloj>rarian++
<ruebot>https://github.com/Islandora-CLAW/CLAW/wiki/January-27%2C-2016#minutes11:04
<whikloj>https://wiki.duraspace.org/display/FF/Islandora+CLAW+Transaction+Use+Case
<ruebot>https://wiki.duraspace.org/display/FF/Islandora+CLAW+Transaction+Use+Case11:05
whikloj++11:06
* barmintor joins11:11
hey- am struggling to get on the call, but trying fww
* mohamedar joins
<ajs6f>barmintor++ # use the telephone, that's how I do it
<barmintor>this phone doesn't have long distance auth11:12
<ajs6f>barmintor: Use a pay phone and a lot of quarters.
whikloj: http://usercontent1.hubimg.com/4642992_f496.jpg # that needs to be photoshopped, and hard
<ruebot>barmintor: you here now? just heard a ding!11:13
* barmintor made it, he finally made it
<ajs6f>barmintor: We're taling about a request to have events for transaction lifecycle boundaries (begin, commit, abort).11:15
ruebot++11:16
escowles_++
<ruebot>https://github.com/fcrepo4-exts/fcrepo-camel-toolbox/releases
https://github.com/fcrepo4-exts/fcrepo-camel-toolbox/releases/tag/fcrepo-camel-toolbox-4.3.011:17
https://github.com/fcrepo4-exts/fcrepo-camel-toolbox/releases/tag/fcrepo-camel-toolbox-4.4.0
oh, right. https://github.com/fcrepo4-labs/fcrepo-camel-webapp11:18
^^^ ajs6f
<ajs6f>ruebot: Thanks, didn't catch that.
<ruebot>yeah, CLAW vagrant moved to karaf11:20
...for camel toolbox
<whikloj>ajs6f++
<acoburn>ajs6f++
<diegopino>ajs6f++11:21
<barmintor>ajs6f++ // never forget
<ruebot>https://wiki.duraspace.org/display/FF/Component+Compatibility+Matrix11:22
<whikloj>ruebot++ escowles_++11:24
<ajs6f>$RELEASE_MANAGERS++
* Piyapong joins
<ajs6f>dwilcox; I want to see you in this: https://www.billboard.com/files/styles/gallery_main_well/public/media/worst-album-covers-of-the-80s-ted-nuggent-billboard-600x600.jpg
<rarian>Sorry I got called away briefly there, so they'll be a gap in the notes.11:25
*there will11:26
<ajs6f>barmintor: Nice use of the word "inflected".
<diegopino>Linked data fragments?? coool11:27
<ajs6f>diegopino: On our radar: https://jira.duraspace.org/browse/FCREPO-1611, https://jira.duraspace.org/browse/FCREPO-161211:28
<diegopino>ajs6f: so damn happy
<ajs6f>diegopino: I was at ISWC 2015 and the Ghent guys were out in force for LDF.
<diegopino>http://ebiquity.umbc.edu/blogger/2015/04/19/access-control-for-a-triplestore-linked-data-fragments-interface/11:29
<barmintor>dwilcox: how long are the papers for the FIG supposed to be?11:30
<ruebot>https://jira.duraspace.org/browse/FCREPO-183011:32
<barmintor>ruebot: who is going to make the tickets for schalk's report to list?
<dwilcox>barmintor: I was looking into that - proposals are supposed to be 2-4 pages but no set length on the papers themselves. Since I am chairing the Fedora IG I can say a short paper would be fine
<ruebot>barmintor: that's a good question. you wanna do it? ...and should we talk about it at all?
<barmintor>ruebot: no but I will, and probably? the feature ticket is more mabiguous.11:33
ambiguous
bagimuous
<ruebot>mabiguous++
<barmintor>ruebot: the feature proposal needs more process, is what I'm saying. Maybe some tech lead input.11:34
ruebot: the bug report is straightforward.
<ruebot>https://groups.google.com/forum/#!topic/fedora-tech/84EzwFUZvJU11:35
<acoburn>whikloj: https://git.io/vz5Xf
<whikloj>acoburn++ # thanks
* Piyapong leaves11:36
<dwilcox>barmintor: Or were you asking about session length for OR papers? Most sessions will be about 30 minutes long including time for questions.11:38
<barmintor>dwilcox: both! thanks, very helpful.
<ruebot>dwilcox: how long are dev track sessions, same?
<dwilcox>ruebot : I assume so - basing this on last year's schedule11:39
<ajs6f>rairan++11:42
<ruebot>rarian++11:44
<barmintor>look at this thorough ticket! Expected behaviors! Links to specifications! A related bug report! https://jira.duraspace.org/browse/FCREPO-187911:53
<ruebot>barmintor++11:56
* yinlin leaves12:05
<barmintor>ajs6f: the drafts of the HTTP-Prefer RFC included a "no-content" option, which I am missing right now12:09
tho I am sympathetic to wanting to minimize the proliferation of header values, too12:10
<ajs6f>barmintor: Yes, it would be nice to leave it up to the client. I just don't know what people are going to do with that body, tho, that they wouldn't do with the header.
<barmintor>agreed, this is what I meant when I said I had a hard time imagining the client able to proceed w/ no body but not use headers12:11
<ajs6f>barmintor: And I want to keep the API mandate minimal.
<barmintor>the escowles_ brought up the interesting case of cURL
<ajs6f>barmintor: Is it really that hard to use cURL to get a header?
<barmintor>no, just another flag
<ajs6f>barmintor: Ay.12:12
<escowles>ajs6f: it's not that hard, but it's more work than URL=`curl -X POST http://localhost:8080/rest/`
<ajs6f>barmintor:escowles: If you are using cURL and you don't want to use flags, you are in the wrong line of work.
<barmintor>fwiw I am probably in the wrong line of work12:13
* barmintor just wants things to work magically
<ajs6f>barmintor: Clap your hands, children, and Tinkerbell will get well, and Fedora will make sense, and _all_ your digital resources will be durable for generations!12:14
<barmintor>yes
that's actually my OR proposal
<ajs6f>barmintor: Tinkerbell is a special effect, an optical trick, like Fedora's API specification.
* bseeger leaves12:17
* ksclarke joins12:36
were there many or proposals in the meeting today? a tentative list of them anywhere?12:51
OR proposals, that is
<ajs6f>barmintor is doing at least twelve.12:52
<ksclarke>heh
<ajs6f>No list, that I know of.
<ksclarke>ok
* pcharoen joins12:54
* pcharoen leaves12:55
* bseeger joins13:38
* diegopino leaves13:58
* bseeger1 joins14:01
* bseeger leaves14:04
* bseeger1 leaves14:05
* bseeger joins14:06
* ksclarke leaves14:07
* bseeger leaves
* ksclarke joins14:24
* acoburn leaves14:35
* acoburn joins14:45
* bseeger joins14:51
* acoburn leaves14:52
* bscoleman joins15:42
sent an email to fedora-tech, and hasn't shown up, so trying here... Is PATCH what I should be using?15:43
Am I approaching this incorrectly? In a federated setup, I have created my external ref to a file within the mounted files, and that works successfully curl -X PUT -H"Content-Type: message/external-body; access-type=URL; URL=\"http://localhost:8080/Fedora4.4.0/rest/federated/jpgs/topos/moos27sw.jpg\"" "http://localhost:8080/Fedora4.4.0/rest/LinksToFederated/topos/MooseQuadSW" I then want to modify some dc: information on
I have 2 rdf files - 1 to insert some metadata dc:title etc, and 1 to remove the data. I run the following statement and it does not fail, however, the data on the nodes is not changed at all: curl -X PATCH -H "Content-Type: application/sparql-update" --data-binary "@deleteMooseMetaData.rdf" "http://localhost:8080/Fedora4.4.0/rest/LinksToFederated/topos/MooseQuadSE/fcr:metadata" Going through the web interface and putting th15:44
INSERT in my rdf file) <> dc:title "Moose Bog Quadrangle" ; dc:date "1927" ; dc:creator "Moose Bog Quadrangle" ; dc:coverage "US Geological Survey" . Succeeds. Then forever more, my PATCH insert/delete is successful Is this not the way I should be doing this?
appologies for length of question
<whikloj>bscoleman: I may be wrong, but could you try applying the PATCH against http://localhost:8080/...../MooseQuadSW15:50
<bscoleman>That fails because it is a binary file.15:51
<whikloj>ok, I thought it should. When you say the data is not updated, how are you checking it? Web UI or GET request?
and does your RDF file have the prefix "dc" defined inside it15:52
<bscoleman>via the web UI
yes. why it is odd that the 2 rdf files work successfully "after" having done an update via the UI15:53
<whikloj>Ohhhh15:54
someone more knowledgable can confirm, but probably the fcr:metadata object doesn't exist. So you should be doing a PUT with your RDF
change the file to straight text/turtle and do something like15:55
<bscoleman>ahhh, so prior to doing the Update via the UI, there is no fcr:metadata. Makes sense. I did try doing a PUT with text turtle. but I wasn't sccessful with that so I thought I had it wrong15:56
<whikloj>I might be wrong, but that is my guess. The fact that you are not receiving an error message is weird though. I would also confirm with a GET using curl15:57
<bscoleman>I can try that. It does look like the fcr:metadata does exist on the object after creation.
<whikloj>bscoleman: then I would use a GET and make sure that it isn't just a browser caching thing :)15:58
you may have been doing this right all along
<bscoleman>worth a try, thanks
* dhlamb leaves15:59
* ajs6f leaves16:09
<bscoleman>PUT will create a new resource with the modified elements. doing a put on the pre-existing element complains on the fcr:metadata and does nothing for the base resource16:17
* dwilcox leaves16:20
<whikloj>but doing a GET on the fcr:metadata does not display the changed properties?16:21
<bscoleman>it does on the correct one, and they are not modified on the incorrect one - so not a caching issue of the browser16:22
it - the one that got changed initially via the webui16:23
<whikloj>ok, so not using the webui you can apply a PATCH to the /fcr:metadata endpoint which does not return an error but does not apply any changes. Have you looked in the Fedora logs?16:24
<bscoleman>correct - next step - I was hoping it was me and there was doing something incorrectly16:25
thanks for helping. I am out tomorrow and will pick up on monday - I will bump up the level of the log messages for debugging and maybe that will help16:28
* bscoleman leaves16:32
* bseeger leaves16:59
* jgpawletko leaves17:09
* jgpawletko joins17:16
* jgpawletko leaves17:19
* dwilcox joins
* dwilcox leaves17:20
* dwilcox joins17:25
* dwilcox leaves17:31
* peichman leaves17:46
* jgpawletko joins17:57
* whikloj leaves17:59
* mohamedar leaves18:05
* jgpawletko leaves18:54
* github-ff joins19:24
[fcrepo4-vagrant] awoods tagged fcrepo4-vagrant-4.5.0 at 4.5.0: https://git.io/vz6D6
* github-ff leaves
* github-ff joins19:25
[fcrepo4-vagrant] awoods deleted 4.5.0 at 5aa7d02: https://git.io/vzFz0
* github-ff leaves
* github-ff joins19:26
[fcrepo4-vagrant] ruebot tagged 4.5.0 at master: https://git.io/vz9qZ
* github-ff leaves
* github-ff joins19:29
[fcrepo4-vagrant] awoods deleted 4.5.0 at 23f0c61: https://git.io/vzFgt
* github-ff leaves
* jgpawletko joins19:51
* dwilcox joins20:16
* dwilcox leaves20:19
* dhlamb joins20:25
* dwilcox joins21:34
* dwilcox leaves
* dwilcox joins22:19
* dwilcox leaves22:26
* dhlamb leaves22:27