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

Using timezone: Eastern Standard Time
* dchandekstark leaves01:11
* dchandekstark joins02:12
* dchandekstark leaves02:16
* dchandekstark joins04:13
* dchandekstark leaves04:19
* dchandekstark joins05:16
* dchandekstark leaves05:21
* dchandekstark joins07:18
* dchandekstark leaves07:22
* dchandekstark joins08:35
* jrgriffiniii leaves08:41
* jrgriffiniii joins09:00
* mikeAtUVa joins09:01
* dwilcox joins09:09
<dchandekstark>awoods: coblej and I are running versions of your script09:11
* coblej joins09:12
<dchandekstark>nothing, right09:15
^ to coblej :)
* mikeAtUVa leaves09:22
<awoods>dchandekstark: good morning09:30
<dchandekstark>awoods: morning
<coblej>awoods: running your script on our development server09:32
* acoburn joins
<awoods>coblej: any news?
<coblej>awoods: objects all created, versioning running now
awoods: no failures so far09:33
<awoods>coblej: I have not yet been able to reproduce failures yet either.
coblej: It is either the test or the environment that must be different from your production setup.09:34
<coblej>awoods: yesterday, I used Hydra/ActiveFedora to create a Collection with 15,000 Items on that same server ... ran our version creation jobs ... encountered the failures
<awoods>coblej: Is it possible to use that same actual collection to do the ingest, but taking Hydra out of the mix?09:35
<coblej>awoods: well, I have been able to reproduce the problem with Hydra/AF created objects on all three of our servers tiers: production, pre-production, and development
* mikeAtUVa joins
<coblej>awoods: I think that might be a logical next step09:36
<awoods>coblej: It also sounds like we need to better understand what Hydra is doing
coblej: But the issue should certainly be reproducible without Hydra in the mix.09:37
<dchandekstark>awoods: I have added more complexity to your script09:38
<coblej>awoods: yes, I think we need to keep working on this piece by piece until we find a reproducible scenario
<awoods>dchandekstark: please feel free to share you updates
<dchandekstark>so that there are two classes of objects, similar to how it looks in our collections
awoods: this is the latest i've run: https://gist.github.com/dchandekstark/0f505ae39ab833948eb5dfd0bd254bf409:41
i tried adding in different factors
like versioning the collection
relating the collection to itself (which we do)
having multiple rels form the objects to the coll09:42
having two levels of objects
adding metadata to the objects
approximating our version labeling
none of it has made a difference running on my workstation
awoods: i am now trying to create a base bones ActiveFedora set up similar to what we use, but very stripped down09:43
just the Collection, Item and Component models and their relationships09:44
no extra Hydra stuff
* peichman joins
<awoods>dchandekstark: You have to be narrowing down on the issue.
<dchandekstark>awoods: i wish i had better setup for files09:45
although nothing so far has suggested the files are a factor
but i want to try a basic ActiveFedora run once09:46
<coblej>the test I ran yesterday (using Hydra/AF) had no files ... just very minimal Collection and Items ... and the problem occurred
<awoods>coblej: perfect, that is helpful.
<dchandekstark>AF I think mostly relies on the Ruby ldp gem to interact with Fedora
<awoods>The other angle to take, which it sounds like you are also doing, is to work from the Hydra-based setup that causes the error and keep removing functionality until the error goes away.09:48
* acoburn1 joins09:51
<dchandekstark>awoods: that may harder, but we'll see09:52
* acoburn leaves
* ajs6f joins09:53
<dchandekstark>awoods: one thing i'm trying initially also is taking Solr out of the equation, which might be tricky in itself09:55
* ajs6f leaves09:56
* ajs6f joins
<awoods>dchandekstark: I guess Solr is pretty integral to Hydra's inner workings.09:57
* acoburn joins
<dchandekstark>it has been09:58
things are slightly different
* acoburn1 leaves09:59
<dchandekstark>awoods: coblej has news10:00
* acoburn1 joins
<awoods>what is your news, coblej?10:01
<coblej>awoods: just reproduced the problem on our dev server using a version of your script
<awoods>coblej: that is great
coblej: can you share the script?
coblej: And can you describe your Fedora install?10:02
<coblej>awoods: yes ... will do so shortly10:03
<dchandekstark>awoods: we're having a conf call with jjtuttle
* acoburn leaves10:04
<awoods>acoburn1: Are you good with: https://jira.duraspace.org/browse/FCREPO-185310:05
<acoburn1>awoods: in a mtg
<awoods>acoburn1: Any comments before merging?
peichman: thanks for your work on: https://jira.duraspace.org/browse/FCREPO-185310:06
peichman: Let's give acoburn1 a chance to comment before we move it in.
<ajs6f>awoods: I am just going to fix #1057 myself. This is getting ridiculous.10:08
<awoods>ajs6f: that would be fantastic. I am sure lsitu would appreciate it.10:10
<ajs6f>awoods: I think we would all appreciate it at this point. I'm not ungrateful for lsitu's work, but we need to move forward.
<awoods>ajs6f: sometimes a PR against the dev PR can help demonstrate exactly what you have in mind.10:11
<ajs6f>awoods: Sometimes reading the JavaDocs for java.util.concurrent can make you a better human being10:12
<awoods>ajs6f: or at least a better java developer10:13
<ajs6f>awoods: I'll settle for that.
<peichman>awoods: sounds good to me10:17
<awoods>mikeAtUVa: are you in a position to try a "simple" migration with one of your existing Fedora4 repositories using /fcr:backup followed by spinning up an empty modeshape5 branch of Fedora repo and invoking /fcr:restore?10:32
* https://jira.duraspace.org/browse/FCREPO-2069
* https://wiki.duraspace.org/display/FEDORA4x/RESTful+HTTP+API+-+Backup+and+Restore
* https://github.com/fcrepo4/fcrepo4/tree/modeshape5
* coblej leaves10:34
<awoods>peichman^^ it would be extremely helpful if you were in a position to do this as well ^^
<mikeAtUVa>awoods: yeah...10:36
<peichman>awoods: we don't have any data in our Fedora 4 repo presently (aside from a handful of skeleton structures like ACLs and groups); but I'd be happy to try this out
<awoods>mikeAtUVa: you are a champ
* ajs6f leaves10:37
<awoods>peichman: also a champ
mikeAtUVa/peichman: thank you both
<peichman>awoods: I will need to coordinate with Ben for some time to do this, probably next sprint
<mikeAtUVa>awoods: I'll let you know how it goes this afternoon.10:38
<peichman>awoods: we are in the final stages of moving our Fedora 4 to production (official launch date Monday), so I am currently occupied with that
<awoods>peichman: that makes sense... although, in terms of time it should only take ~20min
<peichman>awoods: more a question of having the time to context switch to that task :-)10:39
<awoods>peichman: of course. We all know the truth in that.
<peichman>awoods: now back to debugging 11th hour SSL errors…10:40
* ajs6f joins10:41
* coblej joins10:57
awoods: Sorry for the delay ... here is the script that generated the failures on our dev server ... https://gist.github.com/coblej/243b379f99c5687bf5867bf919bd3d9f
awoods: hostname, fedora user, and fedora password changed for purposes of posting10:58
<awoods>coblej: that looks basically identical to the script I have used, no?10:59
coblej: if so, the question may be one of environment11:00
* awoods going into a call
<dchandekstark>awoods: check back on FCREPO-2076 for details of our server env11:01
https://jira.duraspace.org/browse/FCREPO-2076?focusedCommentId=50784&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-5078411:02
coblej: how about running the script on the fedora server?11:03
<mikeAtUVa>awoods: in what way should I convey the results of the mode4-backup mode5-restore test? (it seems to have worked just fine on on fledgling sufia-fronted fedora4 repo, though there's at least one UI issue likely unrelated to the backup restore)11:04
<acoburn1>awoods: I'm +1 on peichman's work on FCREPO-185311:05
peichman++
* coblej leaves11:08
* arebenji joins11:26
* coblej joins11:38
* ajs6f leaves
<coblej>awoods: yes, the script is essentially the same as yours except for the fact that it's using https and that we're providing user credentials
dchandekstark: I did run it on repostore-dev
<dchandekstark>ok - but with ssl11:39
coblej: i'd like to eliminate SSL as a factor
how it could be i'm sure i have no idea
<coblej>dchandekstark: that's fine with me11:40
certainly seems worth trying
* github-ff joins11:44
[fcrepo4] ajs6f created suggestionForlsitu (+6 new commits): https://git.io/vKuIH
fcrepo4/suggestionForlsitu b4a2461 lsitu: Prevent SN-Sibling from creating that triggering the...
fcrepo4/suggestionForlsitu b740b87 Andrew Woods: Add POST test, and refactor
fcrepo4/suggestionForlsitu f3c2267 lsitu: Prevent SN-sibling from creating through POST and refactor the test...
* github-ff leaves
* ajs6f joins
awoods: https://github.com/lsitu/fcrepo4/pull/5 # we will see what comes of that11:47
<ajwagner>Semaphores and futures? Oh my.11:48
<ajs6f>Proper concurrency control. It's the wave of the future.
(See what I did there?)
* ajwagner chuckles11:49
<ruebot>Sorry, we could not display the entire diff because too many files (463) changed.
@_@
<ajwagner>^ Just look at https://github.com/lsitu/fcrepo4/pull/5/commits/c93c1eed2e67f42d96043569d24a6034d7ead715
The rest is just a rebase.
<ajs6f>ruebot: I had to rebase lsitu's PR to even get it to build.
More important than using java.util.concurrent are the in-line comments that _explain what the test is doing_.11:50
<ajwagner>Now I know we really are talking about the future wave, commented clean code? Bah.
<ajs6f>Fedora 4: Our code is so good, it's hypothetical.11:51
afk bbl11:52
* ajs6f leaves11:53
* coblej leaves
<f4jenkins>Yippee, build fixed!11:58
Project fcrepo4 build #3329: FIXED in 13 min: http://jenkins.fcrepo.org/job/fcrepo4/3329/
* travis-ci joins12:39
fcrepo4/fcrepo4#4575 (suggestionForlsitu - c93c1ee : ajs6f): The build passed.
Change view : https://github.com/fcrepo4/fcrepo4/compare/b4a2461bba6c^...c93c1eed2e67
Build details : https://travis-ci.org/fcrepo4/fcrepo4/builds/145038915
* travis-ci leaves
* mikeAtUVa leaves12:53
* ajs6f joins12:57
<awoods>ajs6f: your PR affects 463 files... I suspect that will not be very useful for lsitu.13:07
<dchandekstark>awoods: fwiw i have repeated the failures with coblej's script over the standand non-SSL port 8080
so i think that's out
* mikeAtUVa joins13:08
<ajs6f>awoods: It's because I rebased onto master. He would have had to do that anyway. See the comments in that very PR, or just look ^^^.
<awoods>mikeAtUVa: would you mind adding your details to the ticket: https://jira.duraspace.org/browse/FCREPO-2069 ?13:09
<dchandekstark>awoods: doing another run with 500013:12
<awoods>ajs6f: thanks for the PR, I will resend it against lsitu's PR with just your commit.
<ajs6f>awoods: You can do whatever you want. He's going to have to rebase it.13:13
<awoods>ajs6f: yes
* github-ff joins13:14
[fcrepo-module-auth-rbacl] awoods pushed 2 new commits to master: https://git.io/vKulu
fcrepo-module-auth-rbacl/master 8f34237 Peter Eichman: Remove auto-registration of the AccessRolesResources component....
fcrepo-module-auth-rbacl/master 80a5989 Andrew Woods: Merge pull request #33 from peichman-umd/FCREPO-1853...
* github-ff leaves
<ajs6f>awoods: The only thing I really care much about right now is 2065.
* github-ff joins
[fcrepo-module-auth-xacml] awoods closed pull request #52: Configure XACML to use fcr:accessroles (master...FCREPO-1853) https://git.io/vKRCC
* github-ff leaves
<awoods>acoburn1: would you please merge this PR: https://github.com/fcrepo4-exts/fcrepo-webapp-plus/pull/39
<acoburn1>awoods: sure, did you merge the others already?13:15
<awoods>ajs6f: great. are you working that?
acoburn1: yes
acoburn1: I did not want to merge my own
* github-ff joins
[fcrepo-webapp-plus] acoburn closed pull request #39: Remove auto-registration of the AccessRolesResources component. (master...fcrepo-1853) https://git.io/vK0pX
* github-ff leaves
<ajs6f>awoods: No, waiting for @barmintor to reply to your query. I'll give him until the top of the week.13:16
<awoods>acoburn1: thank you
ajs6f: barmintor replied to me offline yesterday saying: "AuthZ PR about On-Behalf-Of: I haven't had time to look at it. I get the feeling I'm the only one who finds the approach questionable, so if it looks good to you, just ignore me and get a move on."13:17
ajs6f: barmintor is on vacation until the end of the month
<ajs6f>awoods: Oh, I didn't know that. I wish he had put that in the ticket. Okay, in that case, do you know of any object to #1059?13:19
objection
<awoods>ajs6f: not really, although Mirek's interface approach seemed interesting.13:20
ajs6f: I have not tested Mirek's PR, but have tested that the issue he is reporting is real.
* travis-ci joins13:21
fcrepo4/fcrepo-module-auth-webac#151 (master - d4f327f : Andrew Woods): The build passed.
Change view : https://github.com/fcrepo4/fcrepo-module-auth-webac/compare/cdbec77258a5...d4f327fd90d4
Build details : https://travis-ci.org/fcrepo4/fcrepo-module-auth-webac/builds/145060417
* travis-ci leaves
<awoods>ajs6f/ruebot/acoburn1: could one of you review this one: https://jira.duraspace.org/browse/FCREPO-2078
<ajs6f>awoods: Wait, are you saying you don't object or are you saying you don't have anything in _favor_ of #1059.
<awoods>ajs6f: I am saying it looks good, but I have not given a more thorough inspection.13:22
<ajs6f>awoods; Okay, I guess I'll have to look at it. I hate reading computer code.
<awoods>ajs6f: I am also saying Mirek's alternate approach also looks good.
ajs6f: ...maybe even better13:23
<ajs6f>awoods: #1059 _is-_ from Mirek, isn't it?
<awoods>ajs6f: yes, as is: https://jira.duraspace.org/secure/attachment/18030/fedora%20auth.pdf
* travis-ci joins
fcrepo4/fcrepo-module-auth-xacml#118 (master - 257e6b2 : Andrew Woods): The build passed.
Change view : https://github.com/fcrepo4/fcrepo-module-auth-xacml/compare/e124a650f54b...257e6b209a84
Build details : https://travis-ci.org/fcrepo4/fcrepo-module-auth-xacml/builds/145060363
* travis-ci leaves
<ajs6f>awoods: There's no code with that. If mirek wants to write some, great. Otherwise…13:24
* travis-ci joins13:25
fcrepo4-exts/fcrepo-webapp-plus#131 (master - ae83c35 : Andrew Woods): The build passed.
Change view : https://github.com/fcrepo4-exts/fcrepo-webapp-plus/compare/93e0548e84d0...ae83c35c419a
Build details : https://travis-ci.org/fcrepo4-exts/fcrepo-webapp-plus/builds/145060613
* travis-ci leaves
<awoods>ajs6f: if 1059 works (as I suspect it does), I am happy to move forward with it... and keep the interface approach in mind for the future.13:26
* travis-ci joins
fcrepo4/fcrepo-module-auth-rbacl#68 (master - 80a5989 : Andrew Woods): The build passed.
Change view : https://github.com/fcrepo4/fcrepo-module-auth-rbacl/compare/2039ac82bcff...80a59895e128
Build details : https://travis-ci.org/fcrepo4/fcrepo-module-auth-rbacl/builds/145060332
* travis-ci leaves
* awoods grabbing lunch13:27
<ajs6f>awoods: That's what we'll do, then.
* bseeger joins13:42
* peichman1 joins13:56
* peichman leaves13:59
* dwilcox leaves14:01
* awoods back14:03
* bseeger leaves14:11
* coblej joins14:12
awoods: kind of out ideas about what to try next vis-a-vis the version creation issue14:16
awoods: seems that there may be something specific to our server environment that is causing the problem ... no idea what it might be14:17
awoods: if there's anything you'd like us to try, let us know
<awoods>coblej: I would like to be able to reproduce the issue locally... but that may be challenging.
coblej: I do not have RHEL
* dwilcox joins
<awoods>coblej: and I don't have NFS14:18
coblej: I suspect those are two important elements
<coblej>awoods: we might be able to arrange for you (or someone) to be able to access our dev server if that would be useful
<ajs6f>Amongst everyone, we could repro RHEL, a specific NFS setup… that would be hard.14:19
we could repro RHEL, _but_ a specific NFS setup
<awoods>ajs6f: we have a script for reproducing the issue... but have not seen it outside of Duke's environment.14:20
ajs6f: it would be great if we could try it on a UVa's RHEL server14:21
<ajs6f>awoods: It's NFS that seems to me like a botttomless sea of possibility.
<awoods>ajs6f: agreed
<ajs6f>coblej: are oyu guys using leveldb or a sql db?
<awoods>ajs6f: https://jira.duraspace.org/browse/FCREPO-2076?focusedCommentId=50784&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-50784
<coblej>mysql
<awoods>ajs6f: that is Duke's config
<coblej>ajs6f: technically, mariadb14:22
<ajs6f>mikeAtUVa: does what's happening to them sound anything like it could connected with the same pooling weakness oyu described to me yesterday?
<awoods>coblej: have you reproduced the issue on both your dev and prod servers?14:23
coblej: and if so, are those environments identical?
<coblej>awoods: we have seen the issue on all three of our environments: prod, pre-prod, and dev ... though we have run your script only on dev14:24
awoods: the three environments are (should be) pretty much the same on all three tiers
<awoods>coblej: would you be able to remove NFS from dev, for example?14:25
<coblej>awoods: i.e., I am not aware of any intentional differences
<awoods>coblej: or simply run the test configured for local storage?
coblej: is mariadb local?14:26
<coblej>awoods: yes, the mariadb database (ispn) is on a local filesystem14:27
awoods: what's on the mounted NFS storage is are fcrepo directories (com.arjuna.ats.arjuna.common.ObjectStoreEnvironmentBean.default.objectStoreDir, com.arjuna.ats.arjuna.objectstore.objectStoreDir, fcrepo.activemq.directory, and fcrepo.binary.directory"14:29
)
awoods: plus our Java IO tmpdir and the Java GC log files14:30
<awoods>coblej: it appears that the script which was able to reproduce the issue does not upload any binaries: https://gist.github.com/coblej/243b379f99c5687bf5867bf919bd3d9f14:31
<coblej>awoods: to answer your earlier question, yes, we could probably run it all on local storage (for a small test)
awoods: that is correct ... no binaries
<awoods>coblej: in which case, a UVa RHEL/MariaDB setup may be identical enough to show the issue.14:32
<coblej>k
* awoods waiting to hear back from mikeAtUVa regarding ajs6f's query14:33
* mikeAtUVa is catching up with the irc backlog... I'll let you know in a sec..
<ajs6f>From what I remember of our hallway conversation, the issue revolved around the fact that ISPN's connection pooling is shoddy and doesn't use proper test queries.
<awoods>ajs6f: the other corruption we have seen also has tickets in ISPN's jira14:34
<ajs6f>awoods: mikeAtUVa officially hates ISPN.
<awoods>ajs6f: which is one argument for ModeShape5/no-ISPN14:35
<mikeAtUVa>ajs6f: yeah... we would get 500's when a connection was dead, but it wasn't clear that anything was left in a broken state, just that that particular request failed.
<ajs6f>awoods: Do we need any more?
mikeAtUVa: Yeah, I don't think it's a great lead, just wanted to check.
<awoods>ajs6f: no, at this point we just need to demonstrate a reasonable migration recommendation
ajs6f: hence the push for getting validation on /fcr:backup/fcr:restore14:36
<ajs6f>awoods: My migration recommendation is to print your repo out on tractor-feed paper and scan in back in using OCR.
awoods: I thought we were getting rid of fcr:backup/fcr:restore!14:37
<mikeAtUVa>It's not clear to me whether our sufia instance even uses versioning.... Dave couldn't tell me and I don't think I can query the triplestore for that info.
<awoods>ajs6f: unfortunately, it is quite useful
<ajs6f>awoods: So we've reversed that decision?
awoods: When did that happen?14:38
<mikeAtUVa>ajs6f: and as I mentioned yesterday... I think developing a lossless import that retains dates, versions, etc would be non-trivial and shouldn't hold up our move away from ISPN problems.
<ajs6f>mikeAtUVa: Okay, but what does that argue for?14:39
<awoods>mikeAtUVa: one way you can tell if versioning is in place is to look if the fedora:hasVersions predicate exists
mikeAtUVa: that triple only appears after creating the first version of a resource.
<mikeAtUVa>awoods: I looked at a few resources, and saw none, but there's a bunch.
awoods: I wondered if there was a way without poking at random objects until I found that evidence.
<awoods>mikeAtUVa: you could query the triplestore14:40
<ajs6f>You'd think this would something SUfia would document...
would be
<mikeAtUVa>ajs6f: perhaps they did... but if our implementors didn't know, I wasn't going to spend my time digging around.
<ajs6f>mikeAtUVa: No, you have other things to do.
<awoods>mikeAtUVa: and if you do not have a triplestore connected, that is easy to do, then invoke the re-indexer.
ajs6f: re backup/restore, there are different timelines at play14:41
<mikeAtUVa>awoods: we index that triple? Score.
<awoods>mikeAtUVa: what?14:42
<ajs6f>awoods: Sure, but are we or are we not deprecating and eventually removing thos endpoints?
<awoods>ajs6f: those endpoints will by no means be a part of the API Spec...
* dwilcox leaves14:43
<ajs6f>awoods: {sigh} Do we have a continued committement to deprecate and remove them from the current reference implementation.
* awoods side note: I am leaning towards the terminology: "community implementation"
ajs6f: philosophically, yes. But if we want to get people from Fedora 4.6 to 4.7, backup/restore may be invaluable.14:44
<ajs6f>awoods: Fine with me. We can call it the "vanilla impl" or the "mainstream impl" or "community impl" or whatever you want. I took Glen's point at OR.
awoods: Not "philosophically". In reality. As in, post-4.7, we will deprecate and remove those endpoints.14:45
awoods; As part of 4.8.
<awoods>ajs6f: one point of interest, backup/restore creates an exact replica of a repository in another Fedora instance... versions, timestamps, everything.14:46
<ajs6f>awoods: Yes, and there is real work to make a prper RESTful workflow do the same thing. So/
?
<awoods>ajs6f: not true
unfortunately14:47
<ajs6f>awoods: What? You are saying there is not real work to be done there? It's somehow magically already done?
<awoods>ajs6f: using the CRUD REST API does not retain timestamps
<ajs6f>awoods: You are saying the same thing I just said.
<awoods>ajs6f: good
<ajs6f>awoods: If we expect people to be able to switch implementations of the API, we will have to provide a migration pattern that accounts for that. A JCR-base system is useless for that.14:48
<awoods>ajs6f: I completely agree
<ajs6f>awoods: For the last time (I am losing what little patience I ever had for this question), are we or are we not maintaining the decision to deprecate and remove those endpoints?
<awoods>ajs6f: we definitely need to offer tooling for migration workflow... between and Fedora impls and from instances of the same impl...14:49
<dchandekstark>awoods: ajs6f - maybe somebody should update https://wiki.duraspace.org/display/FEDORA4x/RESTful+HTTP+API#RESTfulHTTPAPI-BackupandRestore14:50
?
<awoods>ajs6f: the question is, "is that sufficient"? "Is something more akin to a database dump required"?
<ajs6f>awoods: Are you going to answer the question, or may I assume that the answer is "no" and you are for whatever reason unwilling to admit it?
dchandekstark: Apparently not.
<awoods>ajs6f: I am sorry if we do not live in a black and white world, I am trying to have a discussion.14:51
<ajs6f>awoods: We had extensive discussion about this very issue. The question I just put to you is not a request for a decision, it is a simple matter of communication. The answer is now clear to me, and extremely dissatisfying.14:52
<acoburn1>ajs6f: I've been under the impression that the fcr:backup, fcr:restore endpoints will be deprecated and replaced with command-line tools14:56
ajs6f: that way, if someone wants to migrate from one modeshape repo to another modeshape repo, they can do that14:57
<mikeAtUVa>even if they don't exist in the spec the community implementation essentially requires them at this point.
<ajs6f>acoburn1: It's not surprising you would think that. After all, that very decision was in fact made over a year ago.
mikeAtUVa: No one is suggesting that they be removed before new, better tools are made available.
<acoburn1>ajs6f: are we simply waiting on tooling in order to deprecate those endpoints? because I could write that
<ajs6f>acoburn1: We are apparently not waiting on anything. That decision was thrown away at some point. I do not know why or by whom.14:58
<acoburn1>ajs6f: ok, I'm just mostly confused about those endpoints
<ajs6f>acoburn1: You should be. They are confusing, at best.14:59
<acoburn1>ajs6f: I have another mtg in a sec, but it seems to me that anything going into or coming out of the REST api should be independent of JCR or any underlying impl15:00
<ajs6f>acoburn1: Yes. To my mind, that doesn't forbid individual implementations from offering extended functionality. But as of now, the reference software (community software, etc.) offers important functionality _only_ by a JCR-specific tool.15:01
<acoburn1>ajs6f: yes, yes, extended functionality should be permitted to my mind, too15:02
<ajs6f>awoods: I'll put this down for discussion at the next tech meeting. Frankly, I'm less unhappy about the specifics of the situation than I am about the confusing and to my mind inappropriate way it has developed.15:03
<dchandekstark>ajs6f: is it OK if edit 7-21 mtg page or propose a topic?15:09
<ajs6f>dchandekstark: Absolutely— please do!15:10
<dchandekstark>ajs6f: hopefully, this will be a less controversial topic than ^
:)
<awoods>on a call
<ajs6f>dchandekstark: Well, this is Fedora. Nothing is either totally uncontroversial or worth the worry.15:11
<dchandekstark>ajs6f: fair enough
* dchandekstark leaves15:13
* bseeger joins15:17
* coblej leaves15:18
* bseeger leaves
* bseeger joins15:23
* dwilcox joins15:31
* bseeger1 joins15:32
* bseeger1 leaves15:33
* bseeger leaves15:35
* dwilcox leaves15:45
* coblej joins15:46
* dchandekstark joins16:13
* bseeger joins16:14
* dchandekstark leaves16:18
* dwilcox joins16:27
* bseeger leaves16:29
<acoburn1>awoods: do we really need all that gross jQuery stuff in the javascript?16:35
awoods: can I just remove that and use native methods instead?
awoods: I assume that we're not trying to support IE/8 and before16:36
* dwilcox leaves16:37
* acoburn1 leaves16:39
* mikeAtUVa leaves16:40
* dchandekstark joins16:46
* dchandekstark leaves16:55
<ajs6f>out for the week
* ajs6f leaves
* jrgriffiniii leaves17:04
* coblej leaves17:09
* peichman1 leaves17:13
* dchandekstark joins17:55
* dchandekstark leaves18:00
* jrgriffiniii joins18:19
* dchandekstark joins19:57
* dchandekstark leaves20:02
* dchandekstark joins20:43
* dchandekstark leaves20:48
* dchandekstark joins22:06
* github-ff joins22:19
[fcrepo-camel-toolbox] acoburn pushed 1 new commit to master: https://git.io/vKzCw
fcrepo-camel-toolbox/master 2488daf Mohamed Mohideen Abdul Rasheed: FCREPO-2061. Add ssl authentication capability to the fcrepo-indexing-solr (#93)...
* github-ff leaves
* acoburn joins22:25
<awoods>acoburn: The jQuery stuff is open for refactoring/clean-up. Feel free to hack away.22:33
<acoburn>awoods: ok — I'll save that for a separate effort22:34
awoods: jQuery is fine for some things, but what I see in the code can all be handled with native methods
awoods: plus, that would eliminate another dependency22:35
<awoods>acoburn: you are good that way
<acoburn>awoods: you mean that I like to limit the number of dependencies?
* travis-ci joins
fcrepo4-exts/fcrepo-camel-toolbox#253 (master - 2488daf : Mohamed Mohideen Abdul Rasheed): The build passed.
Change view : https://github.com/fcrepo4-exts/fcrepo-camel-toolbox/compare/b6faa07eafd7...2488daf5abd3
Build details : https://travis-ci.org/fcrepo4-exts/fcrepo-camel-toolbox/builds/145158990
* travis-ci leaves
<awoods>acoburn: indeed
acoburn: you not only like to limit them, you do limit them.22:36
<acoburn>awoods: I have some buddies here in VT that have introduced me to the ways of "going native" with javascript — it's actually quite nice
<awoods>acoburn: has native javascript become more cross browser compatible?22:37
<acoburn>awoods: yes
<awoods>acoburn: that helps, then.22:38
<acoburn>awoods: provided you're not trying to support old versions of IE
awoods: you get css selectors, event handlers, etc. Basically, just about everything that jQuery does
<awoods>acoburn: jQuery must still have a niche, no?22:39
<acoburn>awoods: plugins?
awoods: it's also a bit more concise, but it's kinda bloated in terms of number of kilobytes22:40
awoods: the trend (according to my JS friends) is in moving _away_ from jQuery
awoods: also, if you're targeting FF or Chrome, you can now use the fat arrow operator with lambdas!22:41
<awoods>acoburn: that is interesting to hear
<acoburn>awoods: document.querySelector('#foo .bar').addEventListener("click", (evt) => …)22:42
<awoods>acoburn: it sounds like the world is learning to appreciate the way of the lambda.22:43
<acoburn>awoods: a related question…
awoods: what is the recommended way to develop against the JS code in fcrepo-http-api?22:44
awoods: it seems I have to recompile the module with every change
awoods: surely there must be a better way
awoods: at the very least, I could temporarily modify the template to load the JS from somewhere else and edit it there22:45
<awoods>acoburn: jetty:run does not pick up JS changes and redeploy, does it?
acoburn: Unfortunately, I have always recompiled... but I suspect cbeer had a better way.22:46
acoburn: you may want to reach out to him.
<acoburn>awoods: I may do that, but I think I will try my method first
awoods: another reason to sever the jQuery dependency is that the JS code in fcrepo-http-api depends on jQuery, but jQuery is found in fcrepo-webapp, which inverts the dependency chain22:57
<awoods>acoburn: that could be addressed... but removing the dependency is win-win.23:00
* awoods signing off for the night
<acoburn>awoods: good idea23:01
* acoburn leaves
* f4jenkins joins23:34
* arebenji leaves23:46