Timestamps are in GMT/BST.
[0:41] * awoods (~awoods@c-67-165-245-76.hsd1.co.comcast.net) Quit (Quit: Ex-Chat)
[3:13] * Disconnected.
[3:13] -asimov.freenode.net- *** Looking up your hostname...
[3:13] -asimov.freenode.net- *** Checking Ident
[3:13] -asimov.freenode.net- *** Found your hostname
[3:13] -asimov.freenode.net- *** No Ident response
[6:43] -brooks.freenode.net- *** Looking up your hostname...
[6:43] -brooks.freenode.net- *** Checking Ident
[6:43] -brooks.freenode.net- *** Found your hostname
[6:43] -brooks.freenode.net- *** No Ident response
[6:43] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:43] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:43] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[12:35] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[12:56] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) has joined #duraspace
[17:52] * hpottinger (~hpottinge@mu-161244.dhcp.missouri.edu) has joined #duraspace
[18:27] * helix84 (~a@ip4-95-82-147-170.cust.nbox.cz) has joined #duraspace
[18:41] * barmintor (~ba2213@franklin.cul.columbia.edu) has joined #duraspace
[18:41] <barmintor> is there anyone in the room that has project admin rights for FCRepo in the Duraspace JIRA?
[18:44] <tdonohue> barmintor: I've got full admin rights across JIRA, as do the other DuraSpace tech folks
[18:45] <barmintor> tdonohue: Can I beg you to either give me admin on the FCRepo project, or do a little version-name maintenance?
[18:47] <tdonohue> barmintor: Hmm... according to the FCREPO project, you should already have Admin permissions on that project, since you are a fedora committer
[18:48] <barmintor> Hmm. I don't think it let's me admin anything except Aubra
[18:48] <barmintor> Akubra
[18:49] <tdonohue> Akubra is setup the same way. Since you are an akubra committer, you have Admin rights to that JIRA project.
[18:50] <barmintor> Hmm. Well… I, err...
[18:50] <barmintor> JIRA hates me?
[18:50] <tdonohue> this is through your "barmintor" JIRA username...I'm assuming that's the one you are using since I don't see you under any other login
[18:50] <barmintor> yes, that's right
[18:51] <barmintor> well, this seems like a poor use of our time- could you do me afavor, and add a version called 'Fedora 3.7.1'?
[18:51] <tdonohue> done
[18:52] <barmintor> tdonohue++, thanks much
[18:53] <tdonohue> no problem. you might want to ping andrew on the fcrepo JIRA permissions if there are ongoing issues. I'm not sure why it isn't working, as it seems to be setup correctly
[19:05] <helix84> my favourite pet peeve
[19:06] <helix84> (wrong channel)
[19:23] * bollini (~chatzilla@93-35-50-190.ip53.fastwebnet.it) has joined #duraspace
[19:27] * PeterDietz (~peterdiet@dietz72m1.lib.ohio-state.edu) has joined #duraspace
[20:00] * kstamatis (5b8c1906@gateway/web/freenode/ip.91.140.25.6) has joined #duraspace
[20:00] <tdonohue> Hi all DSpace folks, it's time for our weekly DSpace Developers Meeting. Today's agenda is at: https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-09-18
[20:00] <kompewter> [ DevMtg 2013-09-18 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-09-18
[20:01] <tdonohue> we'll start off with a few Pull Request reviews (as usual): https://github.com/DSpace/DSpace/pulls?direction=asc&page=1&sort=created&state=open
[20:01] <kompewter> [ Pull Requests · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pulls?direction=asc&page=1&sort=created&state=open
[20:01] <tdonohue> today we start off at #287 / DS-1106 : https://github.com/DSpace/DSpace/pull/287
[20:01] <kompewter> [ DS-1106 Solr search accent insensitive (ICU Transliteration) by abollini · Pull Request #287 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/287
[20:01] <kompewter> [ https://jira.duraspace.org/browse/DS-1106 ] - [#DS-1106] Solr search accent insensitive - DuraSpace JIRA
[20:03] <tdonohue> #287 seems reasonable to me, assuming it doesn't conflict with the upgrade to Solr 4
[20:03] <helix84> bollini: does this still return both Cortés and Cortes when you search for Cortés?
[20:03] <bollini> the only "particular" thing about this PR is that we add some extra library to the solr webapp
[20:03] <bollini> helix84: yes
[20:04] <bollini> official solr documentation support adding of these libraries in a special extra folder that is added to the classloader during solr startup
[20:05] <bollini> as we have a custom solr this solution look to me as more easy and out-of-box ready than the official path
[20:05] <helix84> i'm all for the idea, it could just use a second set of eyes to test it
[20:07] <tdonohue> this all seems fine to me
[20:08] <bollini> any progress on the ElasticSearch "not break" test for the solr4 upgrade?
[20:09] <hpottinger> just shouting out here that I'll sign on for testing PR287
[20:09] <hpottinger> though I will say that the big green button looks awfully tempting :-)
[20:10] <tdonohue> ok. So, sounds like we have general approval for #287. Might be good to have a test of it..but then seems good to merge
[20:10] <bollini> no please
[20:10] <bollini> it should be merged after the solr4 upgrade
[20:11] <tdonohue> ok. Good to note. PR#287 needs to wait on #289
[20:11] <bollini> it is very likely to make conflict and this will make more difficult to test the upgrade
[20:11] <helix84> i'll add a comment to wait for solr4
[20:12] <tdonohue> thanks helix84.
[20:13] <tdonohue> Moving on...since it is next in our PR review list: what is the status of #289? https://github.com/DSpace/DSpace/pull/289
[20:13] <kompewter> [ [DS-1623] Upgrade DSpace-SOLR to SOLR 4 by lap82 · Pull Request #289 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/289
[20:13] <hpottinger> I see on my whiteboard that I volunteered to review PR289
[20:13] <bollini> still two missing "no break" test are required: workflow statistics and elastic search
[20:14] <tdonohue> thanks bollini
[20:14] <tdonohue> Anyone able to chip in & help get those tests done in the very near future? We should try to get #289 in very soon...there is a lot waiting on it
[20:14] <helix84> I don't remember if we have a green light from Joao about the oai Solr core
[20:15] <bollini> helix84: yes, you are right also oai need test (but this is likely one that I can do in the next days)
[20:15] <helix84> I see no response from him, I'll remind him again.
[20:15] <helix84> of course if you can do it, the better
[20:16] <hpottinger> we happen to have a very nice new testing environment, would be a fun experiment
[20:16] <tdonohue> hpottinger: was wondering about that ;)
[20:17] <tdonohue> Ok, so sounds like bollini can help test OAI... hpottinger said he may be able to help chip in too
[20:17] <tdonohue> Is that enough to move this forward? Just hoping this doesn't sit around much longer (And I wish I had the time myself, but I'm out most of next week, as you'll see on the agenda)
[20:19] <tdonohue> Ok, hearing no more opinions..so, we'll go with that for now. I would suggest though that we think about merging this soon no matter what (if worst comes to worst, we can do more heavy testing in coming weeks and during testathon)
[20:20] <tdonohue> We'll close up the PR reviews there for today.
[20:21] <hpottinger> I'm on board for testing #289, and if that looks good, following up with #287
[20:22] <bollini> hpottinger: thanks
[20:22] <tdonohue> Next on agenda. I'm gonna be out most of next week (Mon-Thurs) at meetings. So, I'm not going to be around for next week's Developer meeting. Anyone care to lead the meeting next week? I think the only agenda items are 4.0 status updates and doing more PR / JIRA reviews.
[20:23] <helix84> I should be here. The last review seemed to be successful, so we can continue that if nothing else comes up.
[20:24] <tdonohue> helix84: thanks! yea, that seems reasonable to do again, unless there's more pressing 4.0 stuff that comes up. Might be good to check in on #289 again (if it's not merged by then)
[20:25] <tdonohue> moving right along on the agenda. I don't necessarily want to spend a ton of time on this (unless there are a lot of questions). But, hpottinger & I just wanted to formally announce our "vagrant-dspace" work here: https://github.com/tdonohue/vagrant-dspace
[20:25] <kompewter> [ tdonohue/vagrant-dspace · GitHub ] - https://github.com/tdonohue/vagrant-dspace
[20:25] * helix84 gives them a thumbs up
[20:26] <tdonohue> Essentially, you can use this tool to spin up a VM with DSpace ("master" branch) auto-installed. It's a great quick development/test/demo environment
[20:26] <tdonohue> there's much much more details on the GitHub repo (in the README). Feedback is more than welcome. Contributors are more than welcome.
[20:26] <bollini> I haven't tried it but it looks as a good candidate to move under the DSpace github organization
[20:27] <tdonohue> bollini: yes, I was going to ask that too. I'd be completely willing to move this project to "DSpace/vagrant-dspace" in GitHub, if others want to help out. It mostly started as a bit of a sideproject/experiment...but, now that it's WORKING, we could make it more 'official'
[20:28] <helix84> it's been a while since I looked at it, I only vaguely remember something about SSH keys that I didn't like... any idea if that was resolved?
[20:29] <tdonohue> helix84: yep, that was cleaned up a bit better. No more copying your all your local SSH keys to the VM. But, if your local machine is Windows, you do need to create a custom SSH key (details are all in that README)
[20:29] <helix84> and my second concern was with vagrant version, the Vagrantfile syntax wasn't compatible with 1.1
[20:30] <hpottinger> Vagrant is an active project, I suggest keeping up with the current version
[20:30] <helix84> anyway, +1 to moving it under DSpace
[20:31] <hpottinger> the version I'm using right now is Vagrant version 1.2.2
[20:31] <tdonohue> helix84: the VagrantFile version hasn't been changed...mostly we were trying to get something to work. Now that it works, we can go in and clean things up more and add more options/configurations if we really need them
[20:32] <tdonohue> In any case, this is all something everyone else can chip in on more easily if we move it to DSpace GitHub. I'd actually rather not be the sole "decider" of good PRs for this project :)
[20:32] * hpottinger notices 1.3.2 is available and downloads it
[20:32] <helix84> and I have a question - is there any place on the host where you can set options, e.g. the administrator email/password?
[20:33] <tdonohue> helix84: the DSpace Administrator password?
[20:33] <helix84> yes
[20:33] <tdonohue> Some of that stuff is still not as configurable as it should be. Again, we were working to get it to "WORK", and then hoped others would chip in with suggestions/PRs to make it more configurable/better
[20:34] <hpottinger> https://github.com/tdonohue/vagrant-dspace/blob/master/modules/dspace/manifests/install.pp#L26
[20:34] <kompewter> [ vagrant-dspace/modules/dspace/manifests/install.pp at master · tdonohue/vagrant-dspace · GitHub ] - https://github.com/tdonohue/vagrant-dspace/blob/master/modules/dspace/manifests/install.pp#L26
[20:34] <tdonohue> So, the answer is generally: It works as-is, but a lot of it is not as configurable as some developers may want it to be. We'd like you all to help us make it better, if you are willing & want to use it yourself
[20:35] <helix84> hpottinger: thanks, that was the answer to my question :)
[20:36] <hpottinger> you can modify that script to always add your own admin if you want, but I'd only bother if you're planning on jumping in and using Vagrant for your own repository development
[20:36] <tdonohue> So, do folks think we should move this over to "DSpace/vagrant-dspace"? Just want to ask this explicitly, since it's not clear to me if anyone has concerns about that?
[20:36] <hpottinger> +1 move to DSpace/vagrant-dspace
[20:36] <snail> +1
[20:36] <helix84> +1
[20:36] <bollini> +1 to move
[20:37] <mhwood> Sorry, just got here, +1
[20:37] <hpottinger> so big thing I'd like to see added soon is auto-loading AIPs
[20:37] <tdonohue> Ok, sounds pretty unanimous (from those here). I'll move it to DSpace/vagrant-dspace after this meeting ends
[20:38] <helix84> Where shall we record PRs for that project? Simply to DSpace Jira?
[20:38] <helix84> sorry, not PRs, I meant issues
[20:38] <bollini> ah yes, we need a new component
[20:38] <tdonohue> helix84: good question :) Hadn't thought that far ahead yet.
[20:38] <hpottinger> oh, good point, we'll need a wiki space
[20:39] <helix84> GitHub gives us wiki for free, but I was thinking of issue tracker
[20:39] <tdonohue> we probably don't need an entire Wiki space...just a page (though the README is pretty detailed too)
[20:39] <helix84> because I have a feature request I'd like to file ;)
[20:39] * hpottinger is, of course, working on an Oracle-based version, if anyone wants to help.
[20:40] <tdonohue> GitHub has free issue tracking too. But, we probably should just create a 'vagrant-dspace' component in JIRA (to keep the issues all in one place).
[20:40] <bollini> I want to suggest to use the dspace wiki, the development area is a good candidate not a separated space
[20:42] <tdonohue> ok. Well, I can add a new component for it into JIRA. Not sure I'll get to a new Wiki page this week, but we can work towards that as well
[20:42] <hpottinger> if you all haven't yet played with it, it's worth tinkering a bit
[20:43] <tdonohue> Any last comments on 'vagrant-dspace'?
[20:45] <tdonohue> We'll move along then to 4.0 Topics / Discussions. Anything that anyone specifically wants to bring up? (I will note that our 4.0 "initial submissions" PR deadline is now just ~2.5 weeks away)
[20:46] <helix84> Is there still any hope for REST API in 4.0? REST API team? RT?
[20:46] <hpottinger> that's not really a RT decision :-)
[20:46] <tdonohue> good question.
[20:47] <helix84> hpottinger: I meant - are you bugging someone about it? Or is someone bugging you about it?
[20:47] <hpottinger> there is no PR for a REST-API that I know of
[20:48] <mhwood> I haven't heard anything lately. Time for us to see if we can facilitate.
[20:48] <tdonohue> correct, there is currently no PR for REST-API. The question is whether anyone is going to work on one? Or are we skipping it (again) for 4.0?
[20:49] <tdonohue> In my opinion, it'd be nice to have a REST-API, even if we slap "beta" (or other warnings) on it. But, I realize we're getting down to the last few weeks and may have run short on time.
[20:49] <mhwood> Are we even any closer to consensus on *which* API?
[20:49] <helix84> well, there was the option of choosing one of the existing implementations, commiting ourselves to the API and later rewriting the implementation if we don't like it.
[20:49] <hpottinger> there are two versions "in the wild" and "in production" with varying levels of feature sets
[20:51] <hpottinger> I do know that the Wijiti folks are "slightly more interested in supporting" their version, my scare quotes, not an actual quote, and this is strictly rumor-speak
[20:52] <tdonohue> I haven't heard anything else more specific about the REST API than what is already mentioned (and others like PeterDietz and hpottinger probably know more than I)
[20:52] <helix84> It's the classic chicken and egg problem. We seem to be waiting for users to start preferring one, but neither version gets many users since it's not official.
[20:52] <mhwood> Anybody got a coin?
[20:53] <PeterDietz> hi, I have tested PR#289, and commented that ElasticSearch upgrade worked fine. Thus, I'm casting my approval on that.
[20:53] <hpottinger> :-) OK, it's not an easy decision because none of them are feature-complete
[20:53] <tdonohue> In my opinion, if the "REST API Team" (or a set of developers) came and said "we very slightly prefer this one", I'd trust it and go with it.
[20:53] <PeterDietz> Yeah, the REST-API, I'd be plenty happy to have "A REST API" available
[20:53] <bollini> PeterDietz: thanks! this help
[20:54] <hpottinger> Hedtek is read-only, Wijiti is read/write but doesn't do authZ
[20:54] <mhwood> I don't think we are going to get to feature complete without picking one, releasing, and having people start clamoring for features,
[20:54] <helix84> PeterDietz: guess what, you might be the most qualified person here today to make a suggestion!
[20:54] <tdonohue> are either a bit more "complete" in the API specification? Features/implementation can always be added/tweaked later on
[20:54] <PeterDietz> We don't need to hold dspace-rest hostage to dspace-super-awesome-rest-that-I've-always-dreamed-of
[20:55] <hpottinger> well.... I'd have reservations about an "out of the box" web app that doesn't do AuthZ
[20:55] <tdonohue> based on "hpottinger: Hedtek is read-only, Wijiti is read/write but doesn't do authZ", that'd immediately make me lean slightly towards Hedtek (for security reasons)
[20:55] <helix84> plus hedtek has tests
[20:56] <helix84> IIRC, both were ported to 3.0, right?
[20:56] * hpottinger is pretty sure we've had this exact discussion...
[20:56] <PeterDietz> It would be helpful to have the rest cohort around. But, some recommendations are to enforce a versioned API. i.e. Perhaps have 4.0 come out with a dspace.example.edu/rest/v1/communities/
[20:57] * tdonohue agrees with hpottinger, but still we need to keep having this discussion until we make a decision ;)
[20:57] <PeterDietz> How useful is an API that is ReadOnly, vs an API that is CRUD?
[20:58] <helix84> https://wiki.duraspace.org/display/DSPACE/Review+of+Existing+Dspace+REST+API+Frameworks
[20:58] <kompewter> [ Review of Existing Dspace REST API Frameworks - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Review+of+Existing+Dspace+REST+API+Frameworks
[20:58] <mhwood> I'm sure there are good uses for write, but I don't have any myself yet.
[20:58] <tdonohue> A ReadOnly API is actually very useful for some use cases (namely javascript widgets /embedding content in websites, pulling content from Dspace into an external system)
[20:59] <helix84> I'd also be happy with read-only for now
[20:59] <hpottinger> hmmm, Hedtek is PostgresQL-only
[20:59] <tdonohue> The big question in my mind is: Are we gonna have enough time to get something ready for 4.0? We'd need someone to concentrate on moving this forward rapidly...we're only 2.5 weeks away from our "Initial PR" deadline (Oct 7)
[21:00] <mhwood> Even if REST doesn't make the 4.0 cutoff, I would like to see a decision sooner than later. Before 4.0 releases, if not in time to include it.
[21:00] <hpottinger> I do know the Wijiti folks were "very interested" in getting it into DSpace, maybe if someone would invite them to make a PR?
[21:00] <mhwood> Like the RT?
[21:01] <helix84> They both are. But have we decided we want Wijiti?
[21:01] <hpottinger> this RT member was not approached by Wijiti
[21:02] <hpottinger> I think the word on Hedtek is they aren't interested in supporting their REST-API, though, sure, we can reach out to them, too
[21:03] <mhwood> Either way, once it's in, we can study the other for additional features/coverage.
[21:03] <helix84> hpottinger: not Hedtek, but Jorum had it custom-made by Hedtek and Jorum continues to be invested in it
[21:03] <hpottinger> I do think that a PostgreSQL-only version of the REST-API just gets you into a whole other discussion that we don't want to be in
[21:04] <hpottinger> I don't know about Jorum's continued investment in Hedtek's fork
[21:04] <tdonohue> Choose Wijiti if: (1) they submit a PR, (2) they (or we can help) provide an option to either disable "write access" altogether OR add basic AuthZ (I'm worried about Write + no AuthZ as a default setting)
[21:04] <mhwood> How hard to port it to Oracle? (How hard to push the portability layer down to org.dspace.storage.rdbms so we don't keep having vendor-specific code popping up here and there?)
[21:04] <tdonohue> Choose HedTek if: (1) they/we submit a PR, (2) someone can fix it for Oracle.
[21:05] <hpottinger> mhwood: unknown
[21:05] <mhwood> As I feared.
[21:06] <hpottinger> tdonohue: there are "kind of nutty" ways to turn off write access, that will work, but probably won't be something we'd want to release
[21:06] <mhwood> "Basic AuthZ" can mean "refuse if write" and we extend it later.
[21:06] <tdonohue> mhwood++
[21:06] <hpottinger> the "slap-dash" method is to just rewrite the URL endpoints for write operations so they're never hit
[21:07] <helix84> or the write endpoints can be made accessible only for whitelisted IPs
[21:08] <tdonohue> essentially, I think a read-only API is better than a Read/Write with no AuthZ. So, I'd rather Wijiti give us a "read-only" API (or one where "write" is just disabled by default)
[21:08] <helix84> all of which sounds simpler to do than dspace-api-level authZ
[21:09] <hpottinger> yep, we can either whitewash the endpoints away, or delete them
[21:09] <mhwood> If we do that, we may as well just call boolean accessOK(Request req) { return ! ("PUT".equals(req.verb | "POST".equals(req.verb); }
[21:09] <mhwood> "That" = "rewrite the endpoints"
[21:10] <hpottinger> OR, leave them in and add a filter to the web app for localhost
[21:11] <tdonohue> hpottinger: even that is slightly dangerous. If you host is compromised (even for a non-admin acct), DSpace is potentially compromised.
[21:11] <tdonohue> s/you/your/
[21:11] <kompewter> tdonohue meant to say: hpottinger: even that is slightly dangerous. If your host is compromised (even for a non-admin acct), DSpace is potentially compromised.
[21:12] <mhwood> Sorry again, I have to go.
[21:13] * mhwood (mwood@mhw.ulib.iupui.edu) Quit (Remote host closed the connection)
[21:13] <tdonohue> In any case, it sounds like we need: (1) Someone to contact Wijiti about this discussion to see if they are willing to work with us, (2) a PR to get submitted & us to start figuring out if we can make it work.
[21:13] <hpottinger> so... I think I'm hearing: reach out to Wijiti for a PR, bus urge them to change to read-only?
[21:13] <PeterDietz> I'm wondering if a quick-and-dirty basic authentication, on the PUT, POST, DELETE operations would be enough.
[21:13] <helix84> tdonohue: I'm already talking to Michael
[21:13] <PeterDietz> ...can GET do anything to get you in trouble? i.e. expose provenance, restricted items
[21:14] <hpottinger> helix84: welcome back to the RT! ;-)
[21:14] <bollini> hpottinger++
[21:14] <helix84> hpottinger: sorry, not this year, too busy
[21:15] <hpottinger> helix84: act like an RT member, you become one :-) 'tis the way of it. One of us! One of us!
[21:15] <bollini> one of us! one of us!
[21:16] <hpottinger> In all seriousness, thanks, Helix84, for taking that on, even if you don't officially join up.
[21:16] <tdonohue> PeterDietz brings up a good point about the GET access too. There may be issues here
[21:16] <hpottinger> I'd say we're very interested, and would like to see a PR so we can really dig into the discussion with code in hand.
[21:17] <tdonohue> If we make REST API a *default* webapp in DSpace (i.e. it's gonna be installed by default), then we don't want it to be an accidental security hole into DSpace systems worldwide. So, we don't want folks to be able to see restricted items (GET) or write content without secure AuthN/AuthZ (PUT/POST/DELETE)
[21:18] <tdonohue> hpottinger++ We need to see code and do an analysis. Wijiti would get the "lead" if they can work with us on getting it ready.
[21:18] <hpottinger> oh, yeah, duh, we do supposedly offer restricted items and embargo... AuthZ makes that go
[21:18] <tdonohue> yep. AuthZ is needed on GET to
[21:18] <helix84> So, of course they're busy, too, so they probably won't have time to work on it now, but they have been notified. Fact remains that the code is out there ready for some of us to do the last step (actually the same goes for Hedtek API).
[21:19] <helix84> here's what they're working on (based on their API): http://bora-sandbox.wijiti.net/
[21:19] <kompewter> [ Bergen Open Research Archive - HiB ] - http://bora-sandbox.wijiti.net/
[21:19] <hpottinger> anyone interested in making a PR for either of these forks?
[21:21] <hpottinger> maybe we need to offer a bounty on this project?
[21:22] <hpottinger> maybe a kickstarted campaign?
[21:22] <helix84> hpottinger: honestly, no, I believe we need to make a decision
[21:22] <hpottinger> erm... that's kickstarter
[21:23] <hpottinger> well, it's not just a decision, it's a developer taking on the project... a PR doesn't exist
[21:23] <tdonohue> Kickstarter tends to work the other way around... someone says "I want to do this project..will you pay me / support it?" , not "we want someone to do this, will you do it for $$?"
[21:24] <hpottinger> well, you just need an estimate for the work required from a friendly third party vendor, and then you ask people to fund that project
[21:25] <hpottinger> then you pay the third party to write it
[21:26] <hpottinger> I wonder what the "perks" would be
[21:26] <tdonohue> I think we've come extremely close to a decision here (closer than we ever have). We need a "beta-level" API that: (1) has AuthZ for READ (restricted/embargoed items), (2) Optionally, has WRITE access (with AuthN/Z obviously), (3) Meets all current DSpace submission requirements (e.g. PostgreSQL & Oracle support)
[21:27] <tdonohue> So, it's no longer really a HedTek vs. Wijiiti comparison (both fail to meet all 3 of those points). It's more about *who can work with us* to make something we can actually accept into DSpace.
[21:28] <hpottinger> Indeed
[21:29] <helix84> ok, let's make this official and send it out as a call to both developers
[21:29] <PeterDietz> ...or another simplification. A simpler READ api that doesn't expose problems?
[21:29] <hpottinger> how about a call to all developers?
[21:29] <hpottinger> If anyone feels strongly enough to bring a PR to the table, I say let 'em
[21:30] <hpottinger> does this need to come from the Committers, or from the RT?
[21:31] <helix84> I volunteer to send the call with the requirements, to both of them and everyone else on -devel, if we can agree that's what we need
[21:31] <tdonohue> good questions... it might just be an email to dspace-devel?
[21:31] <tdonohue> yes, I think an email to dspace-devel might be a good starting point.
[21:32] <tdonohue> We may also want to capture these requirements over on the Wiki page as well
[21:32] <hpottinger> +1, especially the part where helix84 sends the e-mail :-)
[21:32] <tdonohue> (so they don't get lost in these meeting notes forever"
[21:33] <tdonohue> yea, I'd be glad to have helix84 send the email. I'm swamped these next few days & out next week. I'm here if you need me to review something (e.g. a draft), but I likely won't have time to write up anything myself
[21:34] <helix84> so do we agree it's a competition and whoever can fulfill those requirements goes into 4.0?
[21:34] <hpottinger> and tdonohue is busy moving vagrant-dspace to a new home :-)
[21:35] <hpottinger> hmm... competition implies a prize
[21:35] <PeterDietz> Maybe I'll dust off my jersey and join the race
[21:35] <tdonohue> well, I agree it's a "competition". I'm not sure if anyone will be able to fulfill those requirements *in time for* 4.0, but at least we've clarified the Committers position here.
[21:35] <helix84> yeah, me neither, but the commiters need to finally make a decision
[21:36] <bollini> I'm fine too with an email send to the devel list. We have already make some comments on the current implementations also without a PR
[21:36] <tdonohue> Essentially, the "Committer's Position" is that we don't have a REST API that yet can meet our needs. HedTek and Wijiti are close, but fail in certain areas. We cannot choose either one as neither can be added to DSpace "as-is".
[21:36] <hpottinger> I still don't see this as a committer responsibility, we can't make a decision because we don't have a PR
[21:37] <hpottinger> if it were a Jira issue, it'd be "needs volunteer"
[21:38] <helix84> ok, I see a consensus, so I'm sending the call tonight
[21:38] <PeterDietz> sounds like we reached a good decision milestone. See you all
[21:38] <tdonohue> I agree with hpottinger. We cannot make a decision right now, as there are no "valid candidates" on the table that meet the three points we outlined above.
[21:39] <tdonohue> So the email is all about clarifying what constitutes a "valid candidate" REST API, and then seeing who can step forward to meet those requirements. If multiple folks do, then we have a decision to make.
[21:40] * PeterDie_ (~peterdiet@dhcp-164-107-232-128.osuwireless.ohio-state.edu) has joined #duraspace
[21:40] <tdonohue> and this also does open the doors for others to write a completely new REST API that meets those needs...it's no longer HedTek v. Wijiti (so join the race PeterDietz!)
[21:40] <hpottinger> there's plenty of opportunity for a hungry developer to step up here, there's three possible forks, all sakai-based, and PeterDietz has a Jeresy-based version
[21:40] * kstamatis (5b8c1906@gateway/web/freenode/ip.91.140.25.6) Quit (Quit: Page closed)
[21:40] <bollini> I need to go. Bye all
[21:40] * bollini (~chatzilla@93-35-50-190.ip53.fastwebnet.it) Quit (Quit: ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812])
[21:42] <tdonohue> obviously we're well into "overtime". I don't need to tell you all that. There's no more official topics here, but I think we did make some great headway here on the REST API stuff (even though it means we don't have "valid candidate" REST APIs to decide between)
[21:43] * PeterDietz (~peterdiet@dietz72m1.lib.ohio-state.edu) Quit (Ping timeout: 240 seconds)
[21:44] <tdonohue> helix84: let me know if you want help on this email. If you want, I could even try and find some time to draft it later this week, or on the plane next week (realizing this is a lot to process now)
[21:44] <hpottinger> gotta go, bye!
[21:44] * hpottinger (~hpottinge@mu-161244.dhcp.missouri.edu) has left #duraspace
[21:45] * PeterDie_ (~peterdiet@dhcp-164-107-232-128.osuwireless.ohio-state.edu) Quit (Ping timeout: 268 seconds)
[22:01] <tdonohue> Just for the record, as decided above (by vote) the 'vagrant-dspace' project has been moved to: https://github.com/DSpace/vagrant-dspace
[22:01] <kompewter> [ DSpace/vagrant-dspace · GitHub ] - https://github.com/DSpace/vagrant-dspace
[22:04] * barmintor (~ba2213@franklin.cul.columbia.edu) Quit (Quit: barmintor)
[22:05] <helix84> tdonohue: you may want to re-send the announcement about DSpace/vagrant-dspace to dspace-devel
[22:05] <tdonohue> yea, will do..need to formalize it slightly more
[22:07] <helix84> I just sent out the REST API email and now I'm going to REST, too
[22:07] <helix84> good night
[22:07] * helix84 (~a@ip4-95-82-147-170.cust.nbox.cz) has left #duraspace
[22:22] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.