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

Using timezone: Eastern Standard Time
* ksclarke leaves01:38
* mikeAtUVa joins08:55
* ajs6f joins09:02
awoods: ping09:03
* osmandin joins09:09
* ksclarke joins09:12
<ajs6f>awoods: I realized that my concerns about fixity and the hash-URI thing are unrelated. The hash-URI stuff just happened to bring it up. There is one last point I want to check with you and cbeer on that email thread, and then I can comment up the PR and send it to you.09:14
awoods: I will bring up the fixity stuff Thursday.
<awoods>ajs6f: Are you saying that I should expect an email from you on this point?09:15
<ajs6f>awoods; Yep, in a few minutes.
<awoods>ajs6f: thanks
* awoods leaves09:28
* awoods joins09:29
* ksclarke leaves09:32
* acoburn joins09:33
* ksclarke joins09:37
* awoods leaves09:58
<ajs6f>awoods: We're going to need to document this bnode stuff carefully. Based on @escowles and @birkland's conversation, many people would expect that if you do something like10:00
<resource1> <predicate> _:bnode.
<resource2> <predicate> _:bnode.
in one operation, then the two occurrences of :bnode will be the same resource in the repo, but they will not be. They will each be independent children of <resource1> and <resource2>. That will do fine for the one use case we've ever been given: MODS-RDF. But it's not what some people will expect. The whole ability to do things to resources against which you aren't acting is a bit confusing, although I'm sure some people will find it h
awoods: hang on— I have to be a little more careful about that— in most cases, my code _will_ successfully create just the one skolem resource under the resource against which you are acting via REST. But I couldn't guarantee that. That's a better way to say it.10:03
* dwilcox joins10:05
* github-ff joins10:07
[fcrepo4] osmandin opened pull request #749: Remove equals() for a private utility class with no fields (master...1404) http://git.io/hUjm
* github-ff leaves
* awoods joins10:11
<barmintor_afk>is there a LDP-navigable way to get to versions besides knowing a magic url pattern?10:20
<mikeAtUVa>barmintor_afk: when a resource has versions, there's a relationship returned in the triples.10:34
barmintor_afk: http://fedora.info/definitions/v4/repository#hasVersions10:35
barmintor: http://fedora.info/definitions/v4/repository#hasVersions
<barmintor>mikeAtUVa: when creating a new version, do you POST to the object of that triple?10:36
mikeAtUVa: if the resource is a Binary, is that triple in the fcr:metadata node?10:37
<mikeAtUVa>barmintor: yeah... for creation https://wiki.duraspace.org/display/FEDORA4x/RESTful+HTTP+API+-+Versioning
barmintor: I'd expect so, if you version at that level.
* ithinkiam joins10:39
* ithinkiam leaves10:41
* whikloj joins10:46
<barmintor>So to discover the versions of a binary resource, you would HEAD the resource, get the object of the ldp:describedBy Link header, GET the description, and if there’s a fcr:hasVersions triple POST to its object10:47
to create a new version10:48
or is the interaction model just to PUT to the resource, and have the previous versions roll off?10:50
<f4jenkins>Yippee, build fixed!10:52
Project fcrepo4-T2 build #176: FIXED in 4 min 55 sec: http://jenkins.fcrepo.org/job/fcrepo4-T2/176/
* Nianli joins10:59
* github-ff joins11:06
[fcrepo4] ajs6f pushed 1 new commit to BNodesAreBNodes: http://git.io/hTlq
fcrepo4/BNodesAreBNodes 9d8fc7f ajs6f: Improved JavaDocs
* github-ff leaves
* github-ff joins11:10
[fcrepo4] ajs6f force-pushed BNodesAreBNodes from 9d8fc7f to b59fe63: http://git.io/p5iJ
fcrepo4/BNodesAreBNodes b792e58 ajs6f: First draft, blocked on unintelligible auth ITs
fcrepo4/BNodesAreBNodes be338bb ajs6f: Down to failing tests for hash URIs
fcrepo4/BNodesAreBNodes 0e986f1 ajs6f: Working true blank-node implementation
* github-ff leaves
<ajs6f>awoods: ^^^ all yours
<awoods>ajs6f: thanks11:11
<ajs6f>awoods: I'm going to go work on stuff for D.C. Can you accept a Fuseki config for the hands-on stuff
<awoods>on a call11:12
* travis-ci joins11:14
fcrepo4/fcrepo4#3486 (BNodesAreBNodes - 9d8fc7f : ajs6f): The build has errored.
Change view : https://github.com/fcrepo4/fcrepo4/compare/ab2c2dccbe6d...9d8fc7f2125b
Build details : http://travis-ci.org/fcrepo4/fcrepo4/builds/54582056
* travis-ci leaves
<ajs6f>Weird. Travis is doing that:11:15
$ git checkout -qf 9d8fc7f2125bb8e1752da4683aa2a94069ee75c0
fatal: reference is not a tree: 9d8fc7f2125bb8e1752da4683aa2a94069ee75c0
thing again. I don't even know how it does that.
<f4jenkins>Project fcrepo-module-auth-rbacl build #535: UNSTABLE in 2 min 54 sec: http://jenkins.fcrepo.org/job/fcrepo-module-auth-rbacl/535/11:23
<awoods>ajs6f: re:fuseki-config... I would think so. Have you played around with the Vagrant work here: https://jira.duraspace.org/browse/FCREPO-137711:30
* travis-ci joins
fcrepo4/fcrepo4#3489 (BNodesAreBNodes - b59fe63 : ajs6f): The build passed.
Change view : https://github.com/fcrepo4/fcrepo4/compare/9d8fc7f2125b...b59fe63dfddd
Build details : http://travis-ci.org/fcrepo4/fcrepo4/builds/54582680
* travis-ci leaves
<ajs6f>awoods: no, I have no reason to. i'll cook up a fuseki config for you.
<awoods>ajs6f: cook it11:31
* ajs6f rolls out the Weber and tongs11:32
<f4jenkins>Yippee, build fixed!11:35
Project fcrepo-module-auth-rbacl build #536: FIXED in 3 min 35 sec: http://jenkins.fcrepo.org/job/fcrepo-module-auth-rbacl/536/
* jgpawletko joins11:40
<barmintor>mikeAtUVa: how does FCR4 decide to create versions? Do you mixin fcr:Versionable as a type?
<ajs6f>afk bbl11:42
* ajs6f leaves
<barmintor>the fcr:versions graph is a list of assertions about another subject12:03
<mikeAtUVa>barnmintor (sorry, i was in some marathon meetings) ... you have to create versions explicitly. We used to have auto-versioning (a-la-fedora3) as an option (and even as a default for a while) but all that functionality got the axe in the great paring down of 2014.14:06
barmintor_afk ^^14:07
<barmintor_afk>mikeAtUVa++ // thanks14:25
awoods: is issue #2 subsuming “Should LDPRs have triples for which they are not the subject”?14:48
<awoods>barmintor: can you post issue #2 here?
<barmintor>awoods: Issue-2) Should F4 allow triples that have non-repository subjects?14:57
<awoods>barmintor: yes, I believe Issue-2 is subsuming "Should LDPRs have triples for which they are not the subject"14:58
<barmintor>awoods: I am interested in that part, because fcr:versions is a graph in which all the statements are about other subjects
so there’s an issue of consistency in client expectations
<awoods>barmintor: do you have an example dump of a response to /fcr:versions?14:59
<barmintor>awoods: https://wiki.duraspace.org/display/FEDORA4x/RESTful+HTTP+API+-+Versioning
<awoods>barmintor: I suspect there may be a simple fix of re-crafting the response RDF
barmintor: are you ok with the triple: "<http://localhost:8080/rest/path/to/resource> fedora:hasVersion <http://loca..." ?15:01
barmintor: is the issue you are raising more focused on triples like: "<http://localhost:8080/rest/path/to/resource/fcr:versions/87a0a8c317f1e749515d33-cb73-4fd7-9d1d-c715eb6947e0> fedora:hasVersionLabel "v0"^^<http://www..." ?15:02
<barmintor>barmintor: am *I* ok with it? I dunno, probably, but if it’s okay then I want LDPRs to be able to be able to store statements about other repo resources, at least15:03
* github-ff joins
[fcrepo4] ajs6f pushed 1 new commit to BNodesAreBNodes: http://git.io/hIgJ
fcrepo4/BNodesAreBNodes bb4129c ajs6f: Removing unneeded extra operations in iterators
* github-ff leaves
<barmintor>awoods: the other approach would be to invert the hasVersion stmt
<awoods>barmintor: the question is, are triples on a <resource> with subjects of "<resource>/fcr:versions" an issue in this conversation?15:05
barmintor: if so, then the same argument should be made about <resource>/fcr:metadata having triples with subject <resource>
<barmintor>awoods: I think so, because I think it’s a flawed design for /fcr:versions to have a bunch of special rules15:06
<awoods>barmintor: that same flaw shows up with /fcr:metadata
<barmintor>awoods: yes; I think the examples both suggest that15:07
awoods: or it’s not a flaw, it’s a thing you can do
<awoods>barmintor: or /fcr:* suffixes are special
<awoods>barmintor: or /fcr:* should be #fcr:*15:08
<awoods>probably not
barmintor: I think there are two issues:15:09
1. what about /fcr:* resources and related triples?
2. what about versioning resources that have triples like: "<resource/fcr:versions/c715eb6947e0> fedora:hasVersionLabel "v0"^^<http://www..." ?15:10
barmintor: there is a strong argument for fixing (2)
barmintor: (1) raises deep questions about the F4 REST API15:11
<barmintor>awoods: I think they might turn out to be shallow questions
<awoods>barmintor: joking? or optimistic?
<barmintor>awoods: optimistic!15:12
<awoods>barmintor: please elaborate.
<barmintor>awoods: if you have LDPRs that can contain assertions about other repo resources, those two resources are just that15:13
(in the case of fcr:versions, it’s an LDPC.in the case of fcr:metadata, it’s a LDPR)15:15
<awoods>barmintor: That is clearly a difficult proposal for which to gain consensus. Ideas on shifting the tide in the direction of non-repo triples?15:16
* ajs6f joins
awoods: ping
<barmintor>I think non-repo triples can still be a separate issue
edit: non-repo subjects15:17
<ajs6f>awoods: Are you currently using a FUskei config file, or am I starting from scartch?
<awoods>ajs6f: you are starting from scratch... with some tips offered by acoburn.
<ajs6f>awoods: Where are those tips? I want those tips.15:18
<awoods>ajs6f: you may want to revisit the recent irclog and join barmintor's conversation.
<acoburn>ajs6f: what are you trying to do with a fuseki config?
<ajs6f>awoods: LDPRs are one thing. Non-repo triples is, for me, non-negotiable right now.15:19
I haven't heard one single decent argument for it, and many against it.
acoburn: Just trying to set up simple inferencing— I don't thin kI'm going to have a problem— I haven't tried yet and didn't want to start from scratch if I didn't have to.
<barmintor>ajs6f: summary: fcr:metadata indicates existence of LDPRs that further contain stmts about *repo* subjects, but they are not the LDPR
<ajs6f>barmintor; That was too much of a summary, and I'm not getting any clarity from the log. Are you arguing that fcr:metadta URIs are already LDPRs?15:20
<acoburn>ajs6f: if you look at the jena-fuseki distribution, you should take a look at the config-inf-tdb.ttl file
<acoburn>ajs6f: that will get you started15:21
<ajs6f>barmintor: Okay, I can see that. Sounds like fcr:metadata is wrong. We should get rid of it.
<barmintor>ajs6f: Gotta keep description of LDPNRs somewhere15:22
<ajs6f>barmintor: In the container that holds them.
acoburn: I don't see that guy in my unpacked distro— are you talking about v1 or v2? I'm using v2.
<acoburn>ajs6f: I was looking at the 1.1.1 distro15:23
<barmintor>ajs6f: so when you POST a binary to a LDPC, you get another LDPC that contains it
<ajs6f>acoburn: Okay, cool. See? I already took a wrong turn!
barmintor: You do?
<barmintor>ajs6f: I mean that you would15:24
<ajs6f>barmintor: Not sure. Why wouldn't you just get the LDPNR created?
<barmintor>ajs6f: Well, you get both, but not having fcr:metadata means an intermediate LDPC15:25
<acoburn>ajs6f: for v2, there's this: https://github.com/apache/jena/blob/master/jena-fuseki2/examples/service-inference-1.ttl
<barmintor>ajs6f: it’s like a reversion to the JCR-style fcr:content
<acoburn>ajs6f: and this: https://github.com/apache/jena/blob/master/jena-fuseki2/examples/service-inference-2.ttl
<ajs6f>acoburn++ # he just keeps giving and giving
* dwilcox leaves15:26
<ajs6f>barmintor: Still not _quite_ following you. Why would we create the intermeidating container at all?
* travis-ci joins
fcrepo4/fcrepo4#3491 (BNodesAreBNodes - bb4129c : ajs6f): The build passed.
Change view : https://github.com/fcrepo4/fcrepo4/compare/b59fe63dfddd...bb4129cb8e93
Build details : http://travis-ci.org/fcrepo4/fcrepo4/builds/54616656
* travis-ci leaves
<barmintor>ajs6f: so that there are triples describing the LDPNR somewhere
<ajs6f>barmintor: Why wouldn't those just go into the original LDPC (the one into which you POSTed the binary)?15:27
<barmintor>I mean, fcr:metadata has content. that content is presumably necessary
<ajs6f>barmintor: Sure, we want those triples, but I don't see wy they need their own container.
<barmintor>ajs6f: because their subject is the binary and not the container?
<ajs6f>barmintor: We can't put them in the binary. Okay. So we put them in the fcr:metadata resource. Now we're putting them in the container. What's the diff?15:28
<barmintor>ajs6f: The container is already a thing with its own description.
<ajs6f>barmintor: Sure.15:29
<barmintor>ajs6f: Ok.
* ajs6f is still not seeing the need for an independent RDF Source for each binary in a container.
barmintor: Maybe we're not connecting becuase I'm still seeing this in the Fedora model...15:30
<barmintor>ajs6f: where do you keep triples whose subject is a binary?
<ajs6f>in which the binaries are just aspects of the object.
<barmintor>That is totally false even in FCR3!
<ajs6f>barmintor: Now: in fcr:metadata, I'm saying in future, in some resource that contains the binary.
<barmintor>they’re *contained* in an object (mostly)
<ajs6f>barmintor: We'll just have to agree to disagree again. We already now that we look at F3 and see completely different things, even after years.15:31
<barmintor>ajs6f: No, no, no, this is not that disagreement
<ajs6f>barmintor: I know. I'm saying that I'm not sure it's going to be any more easy to resolve.
<barmintor>ajs6f: what is the FCR4 equivalent of a datastream?15:32
<ajs6f>barmintor: Currently, the combination of binary and accompanying fcr:metadata resource. I'm suggesting we dispense with the latter and make the datastream out of the binary and a slice of the containing object.
<barmintor>ajs6f: what will be the “slice of the containing object”? A bnode that says it describes the binary?15:33
<ajs6f>barminotr: No, no. Just the triples that do describe it. Those tht have the binary's URI as subject.
* dwilcox joins15:34
<barmintor>ajs6f: is the containing object an RDF resource?
<ajs6f>barmintor: Yeah, the way I understand the setup you gave. It's the thing to which you POSTed.
<barmintor>ajs6f: so it would have triples that were not about itself, but about the binary15:35
<ajs6f>barmintor: Yep. No matter where we put the triples that describe the binary, that thing is going to have triples that are not about itself, because they are about hte binary, just he way the fcr:metadata URIs do now.15:36
barmintor: You buy that?
<barmintor>ajs6f: I’m willing to entertain it, but that doesn’t dispel my question about subjects in a given LDPR, it just moves them out of a LDPR into a LDPC15:37
it also puts a fairly annoying tax on clients trying to get the properties of the binary, but that’s an implementation question15:38
<ajs6f>barmintor: Yep. I'm just trying to minimize the number of entities flying about. I don't see this as a use case for LDPRs, I see it as a motivation for simplification.
barmintor: Yeah, I can see that— I would prefer to handle that with LDP's machinery for controlling the kinds of triples you get.15:39
<barmintor>the advantage of the fcr:metadata approach is that it plays nicely with the ldp:describedBy header15:41
(as does any LDPR impl)15:42
<awoods>barmintor: there is also a requirement that if the binary is deleted, so is its description (and vice versa)
<barmintor>awoods: that works well with inserted containers or fcr:metadata; it works somewhat less well with interspersed triples in the LDPC15:43
<ajs6f>barmintor:awoods: True. That would complicate the impl annoyingly.
<awoods>barmintor: agreed
* dwilcox leaves15:44
<ajs6f>barmintor/awoods: Although now that I think about it, I take that back. We already have the gear for that in the of.k.i.rdf.impl RdfContexts.
It wouldn't be hard.
barmintor: To be clear, I'm not against an intermediating container, per se. I want to understand a) is it necessary and b) what does it do for us that other approaches wouldn't?15:45
<barmintor>ajs6f: as far as the client is concerned, it does little that fcr:metadata doesn’t.15:46
<ajs6f>barmintor: Sure. I guess I keep running into the problem that you have to publish the binary-describing triples somewhere, and that place isn't going to be the binary's URI, unless we want to get into scary bad wrong painful HTTP contortions, which I don't want to.15:48
<barmintor>ajs6f: we are if a like mind regarding HTTP contortions
<ajs6f>barmintor: I know! Let's put all the descriptive triples in the header of the actual response to a GET on the binary's URI, in Link: headers.15:49
it’s not 5pm yet, stay with me
<ajs6f>barmintor: It's five PM somewhere in the middle of the ocean.15:50
<barmintor>(although that is basically what marmotta does, and related to why it can’t have RDF data in binaries)
<ajs6f>barmintor: It really is a tricky question.
barmintor: Especially if you take seriously, as I do and I think you do and we now know that Rob Sanderson _really_ does, the admonition to publish at an URI only triples about that URI.15:51
<awoods>ajs6f/barmintor: there are two related questions at hand:15:52
- Should F4 support non-repo subjects
- Should F4 support subjects that are not the target resource
<barmintor>ajs6f: I’m trying to take it seriously, but it is sticky w/r/t binaries and broken in our impl of fcr:versions
<ajs6f>barmintor: Yep.
<barmintor>awoods: yes
<ajs6f>awoods: 1) No. **&*)&*)&) no. 2) We have to.
<awoods>ajs6f: if we have to do #2, then this whole conversation that barmintor is raising is not necessary.15:53
<ajs6f>awoods: Nonsense. We have to figure out how to do 2. The least damaging and confusing way.
<barmintor>?! this whole conversation started b/c I brought up #2!15:54
I’m indignant.
<ajs6f>awoods: Our current choice is fcr:metadata and fcr:versions and barmintor is pointing up some bad problems with them. What's not on about that?
<barmintor>(I’m not *really* indignant)15:56
<awoods>ajs6f/barmintor: we already do #2. You are saying that we should continue to do #2, just better?16:00
<ajs6f>awoods: I just read your original 2 item list more carefully. #1 has nothing to do with this.16:01
It's not related.
awoods: Yes, we have to continue to do #2, unless you have a good idea. I'm all ears.
awoods: In which case, we should do it better. More better, even.
<barmintor>awoods: I’m saying that given that we do #2 in these contexts, the also-questioned assumption about local subjects is probably moot16:02
<ajs6f>barmintor: −5
<barmintor>but it was questioned, like ajs6f was saying, rather vociferously
ajs6f: joke’s on you, I’m irrational
* barmintor bows, soaks in the applause16:03
<ajs6f>Too bad this isn't Google Hangouts. I could give you actual applause sound efx.
barmintor: There's a huge diff between publsihing repo URI-triples at the "wrong" place in the repo vs. publishing triples that are not about repo resources at all.16:05
<barmintor>ajs6f: Maybe, but I meant local as in “local to this resource"16:07
<ajs6f>barmintor: Yeah, I got that— I'm saying that #1 and #2 are just not tied together.
<awoods>ajs6f/barmintor: Currently we have a quasi-rule of "triples on a resource must have a subject that is that resource".
That rule is only "quasi" because we break it with /fcr:metadata and /fcr:versions (and probably elsewhere).
I believe I am hearing that we will continue to break this rule for our /fcr:* resources.
The question then becomes, do we allow users to break that rule?
<ajs6f>awoods: There is really only one place we have to break it— binariues. Anything else we should be able to figure out something better to do16:08
afk bbs
* awoods stepping away for ~30min16:09
<barmintor>awoods: this is the question I was trying to raise, and I was only trying to raise it b/c it wasn’t on your list & was being argued over last week
* osmandin leaves16:10
<barmintor>awoods: the special case of fcr:metadata also touches on LDPR-only in your list.16:11
<ajs6f>barmintor: Do you mean the idea of moving fcr:metadata -> LDPR-only?16:14
back in five minutes
<barmintor>ajs6f: I mean that, as implemented, fcr:metadata *is* an LDPR-only
<ajs6f>barmintor: Right, but we aren't doing any other such resource the same way, and we're not doing the LDP intereaction right, as Aaron said, and it's kind of all a bit hazy.16:15
<barmintor>ajs6f: yes. I want it to be less hazy.16:16
<ajs6f>barmintor: I'm starting to really dislike fcr:metadata
* ajs6f1 joins16:22
* ajs6f leaves16:23
* ajs6f joins16:28
* ajs6f1 leaves
* ajs6f leaves
* ajs6f joins16:34
* acoburn leaves16:46
* mikeAtUVa leaves16:56
<awoods>barmintor: can you succinctly state the missing topic/issue from the list I emailed out?17:26
<barmintor>awoods: “Should RDF Resources contain triples whose subjects are not the resource; cf fcr:metadata and fcr:versions”17:27
<awoods>barmintor: ok. To be clear, this is not an issue that has surfaced in the meta-threads, has it?
barmintor: ok. To be clear, this is not an issue that has surfaced in the mega-threads, has it?17:28
<barmintor>awoods: it came up in one of the mega-threads, but was not the top-level subject
awoods: if you like, I’ll link you the messages I was thinking of17:29
<awoods>barmintor: please
<barmintor>awoods: one minute
awoods: sent17:32
awoods: did you happen to look at the versions google doc I posted this morning?17:33
<awoods>barmintor: ?? where did you post it?
<barmintor>awoods: https://docs.google.com/document/d/1gkfGYpqlD5UShMP7PEe3FdZzcoQIU3F9TF03xY6XUOs/edit17:34
<awoods>barmintor: did I miss something. did you post this document somewhere I should be watching?
<barmintor>awoods: I’m trying to think of a way to describe versions in LDPish terms
awoods: I thought I posted it in more windows than I did17:35
awoods: I think #2 describes the current FCR4 approach17:36
<awoods>barmintor: Do we offer a <versions> link header, presently?
<barmintor>awoods: though there’s no advertising of the link
awoods: no
<awoods>barmintor: that would have been news
<barmintor>awoods: but I’d like to submit a ticket for it, so there’s less reliance on a magic URL17:37
awoods: I don’t even think we have a predicate for hasVersions
<awoods>barmintor: http://fedora.info/definitions/v4/2015/02/04/repository#hasVersions17:38
<barmintor>awoods: Oh! that’s funny- I thought I was looking at RDFLexicon and didn’t see it
awoods: Ohh, sneaky. The constant has a different name than I expected.17:39
<awoods>barmintor: what is the name?
<awoods>barmintor: you are suggesting that all requests for resources come back with a 303?
barmintor: that seems like some extra hopping17:41
<barmintor>awoods: well, not everything is versioned…
<awoods>barmintor: you are suggesting that all <versioned> requests for resources come back with a 303?
barmintor: you are suggesting that all requests for <versioned> resources come back with a 303?17:42
<barmintor>awoods: is the actual URI of the current version in the Location?
<awoods>barmintor: that is a good question. I suspect the location contains a URI along the lines of <resource>/fcr:versions/<some-id>17:43
<barmintor>awoods: IDK, I’m trying to think through what it would be like to turn a generic LDP client on FCR417:44
<awoods>barmintor: the difference between 2) and 3) is support for PUT in 3)?17:45
<barmintor>awoods: yeah, 3 = 1 + 2
awoods: there was a question of whether a client should need to know whether the resource was versioned or not
<awoods>barmintor: re:auto-versioning?17:46
<barmintor>awoods: the PUT behavior was an attempt to accomodate a client that doesn’t care about versions, even if the repo does
awoods: yeah17:47
<awoods>barmintor: due to complexity, we dropped the ability for auto-versioning.
<barmintor>awoods: I know, mikeAtUVA corrected me about it earlier :P
<awoods>barmintor: it would be nice if you were available for these conversations over time, even if you are not available for direct implementation.17:48
<barmintor>awoods: so now I’m just trying to sort out how a client knows where to go to update a resource
awoods: I’l try to become more available17:49
<awoods>barmintor: and you are landing on the link header to help the client?
<barmintor>awoods: it was a thought
<awoods>barmintor: seems reasonable
barmintor: the 303 makes me nervous, because frozen versions are stored in a different repo location and have limited functionality17:50
barmintor: plus the hops
<barmintor>awoods: I’m still not sure. This is why I’m fussing about the fcr:* nodes right now, I’m just trying to make sure I understand the actual model the API implies17:51
<awoods>barmintor: we should continue the conversation tomorrow when mikeAtUVa is around. He is the versioning man.
barmintor: shall we also add the topic to the Thursday tech meeting?
<barmintor>awoods: sure thing. I have a completely clear calendar tomorrow.17:52
<awoods>barmintor: I wish I could say the same
barmintor: have you been working on migration tooling with mikeAtUVa or dlamb or the like?
<barmintor>awoods: I’m working with the ruby scripts for know, our migration is complicated17:53
awoods: some of the objects need to be flattened out, and I’m not sure how to do it w/ any of the tools
* whikloj leaves17:54
<barmintor>awoods: I’ve got the Thursday call on all my calendars
<awoods>barmintor: it would be nice if we could find someone else in the world with the same flattening objects issue
barmintor: it is best not to work in a vacuum
<barmintor>awoods: yeah17:55
awoods: the *easiest* thing to do would be to reorganize them in FCR3 and then migrate, but that will break the existing apps
time for trains. Talk to you tomorrow, awoods17:59
<awoods>barmintor: thanks
* ksclarke leaves18:43
* Nianli leaves21:01
* ksclarke joins21:48
* jgpawletko leaves22:05
* ksclarke leaves22:08
* ksclarke joins22:24

Generated by Sualtam