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

Using timezone: Eastern Standard Time
* manez joins08:14
* dhlamb joins08:18
* snath leaves08:21
* snath joins08:34
* manez leaves08:45
* manez joins08:47
* dwilcox joins08:58
* snath leaves09:08
* dwilcox leaves09:16
* benpennell joins09:17
* bseeger joins09:47
* peichman joins09:49
* peichman leaves09:55
* peichman joins09:59
* osmandin joins10:57
* osmandin leaves11:00
* whikloj joins11:07
* peichman leaves11:48
* peichman joins11:51
* dwilcox joins13:35
* dwilcox leaves14:04
<whikloj>bseeger/benpennell: Thoughts about what would happen if you try to create a Memento with the same date/time as an existing Memento? Is that a 409 Conflict?14:38
<benpennell>whikloj: simply as a matter of opinion, that would be what I would personally want to have happen rather than overwriting or creating two mementos with the same timestamp14:39
requiring a delete and then create seems reasonable14:41
<whikloj>benpennell: cool, so I was working memento creation last night and I was going to generate the path out of the Memento Datetime. Something like http://blah/resource/fcr:versions/20151123041346. See any problems with that?
mostly because I could reuse the existing NodeService copyObject function to make the memento14:42
So the memento's part is YYmmddHHiiss14:43
or I guess actually YYYYmmddHHiiss (I think)14:44
<benpennell>that seems reasonable to me, although we may not want to rely on the semantics of it for functional purposes. I wonder if there is any expectation of retaining fcrepo4 version labels, either via migration or newly create in the api.14:50
<whikloj>benpennell: I wondered about that, but as you can't access a version via a label it seems less than useful to persist14:51
<benpennell>whikloj: i need to catch up on where things currently stand, and this may just be overthinking it, but would my understanding be correct that there is an LDPC with a direct child with the id 20151123041346? I wonder if that could pose any issues with too many direct children in a use case like a repository which automatically triggers versioning on every change14:53
<whikloj>benpennell: fair point, the pid minting stuff is all at the http layer so I can generate a full PID and pass it down with the POST request.14:54
<benpennell>the url pattern for the version is basically the same as the fcrepo4 pattern if you had happened to name your version with a timestamp, which had me wondering a bit if there was any reason why versions shouldn't still be addressable by label14:56
not that i'm advocating for it, i don't think its unreasonable for users to have to use new uris to address versions post migration since the versioning api is new. but I'm not currently running a repo using fcrepo4 versioning.14:58
<whikloj>benpennell: So the difference would be the thing you pointed to with using the date. Each is now a first class resource inside of the TimeMap, so you could hit the many members issue. Whereas before we were using the Modeshape versioning functions to create/store/revert and remove versions15:04
<benpennell>whikloj: yes, true, i don't know how the modeshape versioning code performed relative to the regular resource functionality. the label/slug mechanism is pretty consistent between versions and regular resources in fcrepo4.15:10
<whikloj>benpennell: yeah, I guess I was thinking that all version access through go through datetime negotiation, whereas the old versioning was all via...what label you want to access.15:11
therefore labels are less important, but I'm not sure
<bseeger>(bseeger is following along here, but doesn't have anything to add)
<benpennell>whikloj: yes, i agree that labels are less important, there just doesn't seem to be a strong reason they can't be supported.15:14
but being able to tell the timestamp of the version seems consistent with other memento implementations i've seen, and directly relates to api, so as long as we aren't making too many promises about it i think its not a bad thing to use in the version uri15:15
<whikloj>bseeger: why not?! We are just looking for opinions, should we keep labels.
<bseeger>whikloj, benpennell - not sure if I'm behind in a few steps here, but I just want to see if I get this. Given the above conversation, one could access a memento directly through a URL if you knew the address. But if you didn't know the address you'd make a call to the http://example.com/resource/uri with an Accept-DateTime header, get a URL back and then ask for it. Is that correct?15:16
<whikloj>bseeger: yes
benpennell: so here is my question, if you want to migrate versions. Would you just supply the version label as a separate property?15:21
benpennell: or do you think that you (or others) would like to use the label as the URI?15:22
<bseeger>whikloj: what would the URI be otherwise? A pair tree? Guess I'm not totally following this…15:23
<whikloj>bseeger: Initially I was going to create the URI out of the memento date/time. Mostly because the PidMinter is injected at the HTTP level. So now we are discussing whether we allow version labels could be used instead.15:25
<bseeger>whikloj: in either case, it would look the same to the client? ie, still http://blah/resource/fcr:versions/20151123041346 — but behind the scene the implementation details would be different depending on what you end up choosing to use (labels or the PidMinter)? Oh…15:27
or would the new URL not have the fcr:versions in it?
if it was created by the PidMinter…
<whikloj>bseeger: no I think the URL would always start with the http://blah/rest/originalResource/fcr:versions/something, the question is "something" the old version label or the memento datetime or ab/cd/ef/abcdef15:31
s/the question is "something"/the question is is "something"/
<bseeger>whikloj: ah, okay. I think I get it now.15:32
whikloj: so if I migrate versions to 5.0.0 and a I have a version named 'banana', are you asking if we'd still want it to be known and accessible as 'banana' in 5.0?15:37
http://blah/rest/originalResource/fcr:versions/banana15:38
<whikloj>bseeger: yes, should banana be part of the URI?
<bseeger>whikloj: ah, I see (slow today, sorry. ;). My preference would be to no longer have the labels… but use the timestamp instead for consistency… but I need to think about that a little.15:39
<whikloj>fair enough15:44
* manez leaves15:46
* manez joins16:14
<benpennell>whikloj: doing an initial implementation with just having a system specified uri (no label) seems reasonable to me. if users would like to add labels back in during beta testing it doesn't seem like it would be a major effort. So I support your current approach, just wanted to talk it out some :)16:17
* manez leaves16:18
<whikloj>benpennell++16:19
benpennell: as someone who doesn't use Fedora 4 I constantly need some confirmation, so thank you for that
* peichman leaves17:31
* whikloj leaves17:50
* bseeger leaves17:52
* benpennell leaves17:53
* dhlamb leaves18:10
* travis-ci joins18:45
ualbertalib/fcrepo4-oaiprovider#126 (fcrepo_4.7.4 - f3ad48f : Jeffery Antoniuk): The build passed.
Change view : https://github.com/ualbertalib/fcrepo4-oaiprovider/compare/3d1b2d59b333...f3ad48f3dc52
Build details : https://travis-ci.org/ualbertalib/fcrepo4-oaiprovider/builds/305018314
* travis-ci leaves
* benpennell joins19:40
* benpennell1 joins19:41
* benpennell leaves19:45
* benpennell1 leaves20:04
* benpennell joins20:14
* benpennell leaves
* dwilcox joins20:31
* dwilcox leaves20:43
* dhlamb joins21:58
* benpennell joins22:11
* dhlamb leaves23:27

Generated by Sualtam