Timestamps are in GMT/BST.
[0:46] * jonathangee (~jgreen@blk-142-16-43.eastlink.ca) has joined #duraspace
[1:41] * eddies1 (~eddies@unaffiliated/eddies) Quit (Quit: Leaving.)
[1:50] * jonathangee (~jgreen@blk-142-16-43.eastlink.ca) Quit (Quit: jonathangee)
[6:30] -hubbard.freenode.net- *** Looking up your hostname...
[6:30] -hubbard.freenode.net- *** Checking Ident
[6:30] -hubbard.freenode.net- *** Found your hostname
[6:30] -hubbard.freenode.net- *** No Ident response
[6:30] [frigg VERSION]
[6:30] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:30] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:30] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[8:40] * scottatm (~scottatm@adhcp210.evans.tamu.edu) Quit (Read error: Connection reset by peer)
[8:41] * scottatm_ (~scottatm@adhcp210.evans.tamu.edu) has joined #duraspace
[12:59] * jonathangee (~jgreen@142.176.125.60) has joined #duraspace
[13:36] * jonathangee (~jgreen@142.176.125.60) Quit (Quit: jonathangee)
[14:02] * tdonohue (~tdonohue@c-50-129-94-92.hsd1.il.comcast.net) has joined #duraspace
[14:41] * jonathangee (~jgreen@142.176.125.60) has joined #duraspace
[15:56] * jonathangee (~jgreen@142.176.125.60) Quit (Quit: jonathangee)
[15:56] * jonathangee (~jgreen@142.176.125.60) has joined #duraspace
[15:57] * njefferies (a301cb45@gateway/web/freenode/ip.163.1.203.69) has joined #duraspace
[16:00] * eddies (~eddies@cm18.epsilon183.maxonline.com.sg) has joined #duraspace
[16:00] * eddies (~eddies@cm18.epsilon183.maxonline.com.sg) Quit (Changing host)
[16:00] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[16:35] * njefferies (a301cb45@gateway/web/freenode/ip.163.1.203.69) Quit (Quit: Page closed)
[19:33] * KevinVdV (~KevinVdV@d54C154B1.access.telenet.be) has joined #duraspace
[19:44] * helix84 (a@195.113.97.174) has joined #duraspace
[19:49] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has joined #duraspace
[19:51] * PeterDietz (~peterdiet@128.146.173.112) has joined #duraspace
[20:00] <tdonohue> Hi all...running a bit late today. Obviously it's now time for our DSpace Devel Mtg
[20:01] <tdonohue> Agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-12-19
[20:01] <kompewter> [ DevMtg 2012-12-19 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-12-19
[20:02] <tdonohue> So, we'll go ahead and start off with a couple of unassigned JIRA tickets today...just to get back into the habit of reviewing old tickets..
[20:02] * joaomelo (~DSpace@188.250.43.157) has joined #duraspace
[20:02] <tdonohue> So, reminder, the goal of these quick JIRA reviews is to just do a very quick analysis, possibly find a volunteer
[20:03] <tdonohue> here's a list of our backlog...I'm going to skip over tickets that are already assigned.
[20:03] <tdonohue> https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+resolution+%3D+Unresolved+AND+Key%3E%3DDS-1082+ORDER+BY+key+ASC
[20:03] <kompewter> [ Issue Navigator - DuraSpace JIRA ] - https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+resolution+%3D+Unresolved+AND+Key%3E%3DDS-1082+ORDER+BY+key+ASC
[20:03] <kompewter> [ https://jira.duraspace.org/browse/DS-1082 ] - [#DS-1082] Invalid embargo causes item archival to crash - DuraSpace JIRA
[20:03] <tdonohue> so, we'll start with DS-1083
[20:03] <kompewter> [ https://jira.duraspace.org/browse/DS-1083 ] - [#DS-1083] Create new users from the command line - DuraSpace JIRA
[20:05] <tdonohue> seems like something that'd be a good idea, just really needs someone to figure out a nice solution / implementation. mhwood's comments are good
[20:05] <tdonohue> so, it's essentially just waiting on a volunteer to move forward with it
[20:05] <PeterDietz> Is the rest-api read-only nowadays?
[20:06] <joaomelo> yes
[20:06] <tdonohue> which one -- there's 3 rest-api's :)
[20:06] <PeterDietz> If it was read-write, you could POST some new users to do this
[20:06] <helix84> tdonohue: you meant stuart's comments?
[20:06] <tdonohue> helix84 -- stuart pasted in comments from mhwood (see second comment)
[20:06] <helix84> tdonohue: ah, nevermind
[20:06] * cbeer (cbeer@2600:3c03::f03c:91ff:fedf:a498) has left #duraspace
[20:07] <PeterDietz> who is "Eric Oliver" (that it was at one point assigned to)
[20:07] <helix84> only the hedtek rest api is read-only
[20:07] <helix84> original and wijiti are read-write
[20:07] <tdonohue> But, PeterDietz -- I agree, it's possible some of this could be done via a REST API, once we actually adopt a REST API.
[20:07] <tdonohue> no idea who Eric Oliver is...we'd have to look back at the dspace-devel archives from Nov 2011
[20:07] <PeterDietz> (I notice there is a bit of chicken vs egg)
[20:08] <joaomelo> wijiti looks good, i'm using it
[20:08] <helix84> latest report on REST API - Hedtek was doing only contract work for Jorum, so they won't actively work on it now,
[20:09] <helix84> Jorum is porting the Hedtek version to 1.8, they're mostly finished by now
[20:09] <helix84> Jorum is interested to work to get _some_ REST API into DSpace proper
[20:09] <helix84> (I suggested them to cooperate with Wijiti)
[20:10] <joaomelo> yes, i was looking to porting wijiti to 3.0
[20:10] <tdonohue> good to know those REST API statuses. I haven't used either hedtek or wijiti, but I'm interested in what folks think of either. The main bonus I saw to the hedtek, was that it came with full unit testing (which is awesome), but I know it's more limited (read-only)
[20:10] <joaomelo> 3.0+
[20:10] <helix84> I haven't talked to Wijiti lately, but they're surely also interested in upstreaming REST API
[20:10] <helix84> basicelly we just need to get them to cooperate, which I've been trying
[20:10] <helix84> I'll contact Wijiti this week
[20:11] <joaomelo> mama is calling, need to run
[20:11] <joaomelo> bye
[20:11] <kompewter> bye!
[20:11] <hpottinger> I'm interested in working with a REST-API with 3.0, anyone catches wind of anyone porting to 3.0, I'd pitch in
[20:11] * joaomelo (~DSpace@188.250.43.157) Quit (Quit: joaomelo)
[20:11] <helix84> hpottinger: currently wijiti is available for 1.8
[20:12] <tdonohue> +1 if anyone does do some porting of either REST API to 3.0, it'd be great to advertise so we can start to work on getting an "official" REST API adopted in time for 4.0
[20:13] <helix84> well I think porting to 3.0 will be mostly correcting path names due to Maven Project Consolidation, right?
[20:13] <tdonohue> Ok. we've gone off on a bit of a tangent here to discussing REST APIs, but it's a good tangent (so I'm not gonna stop it)
[20:14] <helix84> yea, many people would really like to see a REST API finally in 4.0, some good stuff depends on it
[20:14] <tdonohue> helix84 -- not sure that Maven Consolidation would even really affect the REST API, as it should be just using classes out of dspace-api. But, I don't imagine there'd be much work to get a REST API working on 3.0 if it's already working on 1.8
[20:15] <KevinVdV> Where is the rest api (IF I should find the time) ? (on github that is)
[20:15] <PeterDietz> So the ticket Ds-1083, isn't neccessarily command-line user provisioning, its batch user operations
[20:15] <helix84> https://github.com/hedtek/dspace-rest
[20:15] <kompewter> [ hedtek/dspace-rest · GitHub ] - https://github.com/hedtek/dspace-rest
[20:15] <helix84> here's hedtek
[20:15] <tdonohue> Here's the Wijiti REST API (which joao said he likes): https://github.com/wijiti/dspace-rest-api
[20:15] <kompewter> [ wijiti/dspace-rest-api · GitHub ] - https://github.com/wijiti/dspace-rest-api
[20:16] <tdonohue> it's essentially down to those two REST APIs...the 3rd REST API (https://github.com/DSpace/dspace-rest) was just a Google Summer of Code project and it's a bit unstable
[20:17] <helix84> both of those built on the original GSoC project
[20:17] <tdonohue> yep. hedtek & wijiti built a more stable version of the original GSoC project
[20:17] <helix84> btw hedtek is working on removing this thing called sakai bus manager... or something
[20:18] <helix84> ehm, not hedtek, jorum (on the hedtek version)
[20:18] <tdonohue> "Sakai EntityBus"
[20:19] <tdonohue> It was the technology that the original REST API used to do the REST work...there's much better ways to write a simple REST API these days (Spring, etc). So, trying to get rid of the Sakai EntityBus is probably a good thing
[20:19] <helix84> is there anyone who tried _both_ APIs and can tell us their experience?
[20:20] <PeterDietz> I've only used the hedtek version
[20:20] <tdonohue> sounds like no-one. I'd also be interested in hearing from anyone who has used both (I haven't)
[20:21] * DoctorLard (~johnno@9.109.124.202.static.snap.net.nz) has joined #duraspace
[20:21] <helix84> hi jonathan
[20:21] <tdonohue> PeterDietz -- did you like the hedtek version? Any feedback on it?
[20:22] <PeterDietz> Its read-only, and at the time, that was the scope of my interest. I found it to be much better than the gsoc rest-api
[20:22] <- *DoctorLard* +1 Wijiti version of REST API - have it running nicely in a test instance.
[20:22] <PeterDietz> It never crashed / timed-out
[20:22] <hpottinger> I've said this before, but I like the hedtek focus on testing, and I like the read-only aspect as well
[20:22] <PeterDietz> Some options weren't quite working, I think there was an email thread sharing that back to hedtek
[20:22] <DoctorLard> +1 Wijiti version of REST API - have it running nicely in a test instance.
[20:23] <DoctorLard> it's built on the hedtek version
[20:23] <tdonohue> The pros I've heard (from others) about the hedtek REST API were exactly those things -- it has unit testing, it's very scalable, it's read-only (which can be a benefit in some ways, and a detriment in others)
[20:23] <helix84> btw that hedtek is currently read-only doesn't mean that it can't be easily extended for write functions - it only means they didn't need them, so they focused on read, performance and tests
[20:24] <helix84> DoctorLard: really? i didn't know that
[20:24] <DoctorLard> it seems to be in the commit history
[20:24] <tdonohue> I thought the wijiti version was based on the original Google Summer of Code project? (at https://github.com/DSpace/dspace-rest) Really, it's based on hedtek?
[20:26] <PeterDietz> hmm. They aren't proper forks
[20:26] <tdonohue> looking...I don't see any similarities in the commit history of wijiti and hedtek...maybe I'm just missing it?
[20:27] <PeterDietz> Maybe the "initial import" commits mean starting from previous project
[20:27] <DoctorLard> hmm.
[20:27] <helix84> wijiti starts with copying the rest module to the dspace source
[20:27] <helix84> jonathan, did you mean that wijiti started by forking the original GSoC project?
[20:27] <tdonohue> yea, my understanding were they both started from the original GSoC project (dspace/dspace-rest)
[20:27] <DoctorLard> http://paste.jon.geek.nz/c1d171
[20:28] <DoctorLard> but maybe that's not really a "fork" - more a "replacement"
[20:29] <helix84> DoctorLard: how did you get that graph? I see that wijiti starts with 8a9490d, so how can there be anything before that?
[20:30] <helix84> ok, nevermind, i'll take a closer look after the DevMtg
[20:30] <helix84> and I'll talk to wijiti
[20:30] <DoctorLard> git log --graph --decorate --oneline wijiti/master
[20:31] <tdonohue> yea, we can figure this out later... either way, they've gone off in separate directions (even if they started from a mostly "common" codebase)
[20:31] <helix84> DoctorLard: thanks, i'll take a look later
[20:31] <DoctorLard> :P weird.
[20:33] <DoctorLard> well Wijiti were keen to port it to 3.x next month budget permitting.
[20:33] <hpottinger> either way, the tests from HedTek should in theory work against another REST-API, so, in theory, we should be able to consolidate the two forks
[20:33] <tdonohue> I definitely hope we can all try to find some time to try out both hedtek & wijiti and see which we prefer. I think there's also a possible area for having multiple REST APIs (e.g. a read-only, and a read/write), but we probably would want them to not be 100% different codebases
[20:34] <PeterDietz> It looks like Hedtek's version went dormant, and then Wijiti picked up from where they left off.
[20:34] <DoctorLard> It should certainly be configurable - at the very least, "rest-readonly = true" or similar.
[20:34] <PeterDietz> I would say the Wijiti version = Hedtek + Further Improvements
[20:34] <PeterDietz> And Hedtek = Original GSoC + Improvements - Write
[20:35] <helix84> it didn't go dormant. hedtek finished they contract work for jorum and they've been using it (and improving it, e.g. the 1.8 port, removing entitybus) internally
[20:35] <DoctorLard> ah, wijiti still using entitybus methinks?
[20:35] * DoctorLard checks quickly
[20:35] <PeterDietz> dspace-rest github fork of dspace-rest api with development of integration tests Last updated 9 months ago
[20:35] <helix84> yes
[20:36] <DoctorLard> yes
[20:36] <DoctorLard> is that bad? :)
[20:37] <helix84> depends. they both have different improvements since then.
[20:37] <helix84> best thing would be to get them work together and sort it out, which i started trying recently
[20:37] <DoctorLard> (thanks for supporting pull #107 btw, there will now be slightly fewer surprised DSpace 1.8 github users!)
[20:38] <tdonohue> PeterDietz -- but, wijiti was also last updated (at least in GitHub), 6 mos ago. It looks like there was a period where *both* Wijiti and Hedtek were actively developing...so, the codebases may be somewhat similar, but I don't think they are the same (i.e. I don't think Wijiti is a complete fork of all Hedtek improvements
[20:38] <helix84> let's move on, we can get back to REST API when we have more news
[20:39] <tdonohue> yea, let's move on...Obviously the next steps are to try each out, and work to adopt one or merge them
[20:39] <tdonohue> OK, next topic was just the ongoing one on 3.0 / 3.1 updates
[20:40] <tdonohue> I also wanted to specifically point out that it seems, at least so far, we have no reports of anyone being able to install 3.0 on Oracle.
[20:40] <tdonohue> see also DS-1435
[20:40] <kompewter> [ https://jira.duraspace.org/browse/DS-1435 ] - [#DS-1435] DSpace 3.0 Oracle compatibility - DuraSpace JIRA
[20:40] <helix84> didn't hardy manage to do that locally?
[20:41] <tdonohue> nope...hpottinger created the issue I just linked to
[20:41] <tdonohue> as far as we are aware, no one has been able to install 3.0 on Oracle
[20:41] <DoctorLard> ORA-00904: "TRUE": invalid identifier <-- Oracle bug
[20:41] <DoctorLard> -__-
[20:42] <tdonohue> But, if anyone is willing to give it a try, we could use help here. I think we are still uncertain what the exact issues are, unless hpottinger has figured anything out
[20:42] <helix84> DoctorLard: I think that one was fixed post 3.0 and is in the 3.1 branch
[20:42] <hpottinger> no, very many balls in the air here, as always
[20:42] <helix84> tdonohue: no, I meant before we released 3.0
[20:43] <hpottinger> definitely need help identifying errors and stack traces for Oracle issues, and helix84, I did raise a flag before pressing the big release button
[20:43] <tdonohue> helix84 -- yea, the answer is the same. I don't think anyone ever actually got 3.0 or pre-3.0 working on Oracle. We just fixed that one minor bug in the Oracle DB upgrade script prior to 3.0 final
[20:44] <helix84> ok, all i can do is link all the threads that could help to today's hardy's jira issue. but i'm not using oracle...
[20:44] <hpottinger> and I tried an upgrade to our 1.7 DB, and ran into issues, and then ran into more issues with our 1.7 DB and have been basically railing against Oracle for weeks
[20:45] <helix84> btw hpottinger++ for the debug tip, I'll recommend it to everyone who runs into DB problems
[20:45] <DoctorLard> Oracle, Y U NO Boolean!
[20:46] <hpottinger> the really fun part is you can't download a version of Oracle to run on OSX any more...
[20:46] <helix84> how comes? i thought oracle = false, at least in my shop!
[20:46] <tdonohue> Is it still possible to get a free copy of Oracle, just for testing?
[20:46] * helix84 checks... no oracle = 0 ;)
[20:46] <hpottinger> Yes, you can still download Oracle for Linux and Windows, just not for OSX
[20:47] <helix84> tdonohue: yes, there's a version with some limits, like 1 GB
[20:47] <DoctorLard> Oracle needs to die in a fire.
[20:47] <hpottinger> DoctorLard++
[20:47] * hpottinger looks around nervously...
[20:47] * helix84 looks around
[20:47] <helix84> lol
[20:48] <helix84> no zealots in sight
[20:48] <helix84> tdonohue: are you willing to give it a try?
[20:48] <hpottinger> to complicate things even more, we're seriously considering jumping off the Oracle train here...
[20:48] <tdonohue> So, it seems like the first step would be to find someone with some time to even just verify things are bad.... (1) download Oracle, (2) try to install Dspace, (3) report whether it works or not. Assuming #3 = it's broke, then we at least verified we definitely have an issue here.
[20:49] <helix84> basically, who needs oracle support in dspace needs to step up and maintain it
[20:49] <tdonohue> I'm not likely to have a chance to try Oracle + Dspace 3.0 this week, and after this week I'm off from Dec 22 - Jan 2.
[20:50] <DoctorLard> hpottinger: I have Oracle --> PostgreSQL stories, revolving around why Oracle don't like people publishing benchmarks.
[20:50] <tdonohue> Currently, if hpottinger stops using Oracle, I'm not sure we have any other (active) Committers using Oracle.. grahamtriggs used to do Oracle help..but I'm not sure he's doing that anymore in his new job. I've heard rumors that @mire may be doing some Oracle?
[20:51] <tdonohue> beyond those folks, I think everyone else uses Postgres
[20:51] <helix84> tdonohue: no, I think @mire are happily migrating users off of JSPUI and Oracle :)
[20:51] <tdonohue> oh, ok. good to know.
[20:51] * joaomelo (~DSpace@188.250.43.157) has joined #duraspace
[20:52] <helix84> but i know some local oracle institutions here
[20:52] <helix84> but i'm not sure they'd be up to the task
[20:52] <tdonohue> so, essentially, our current Oracle support = hpottinger. We may need to shake the bushes to see if we can find some others to help, or stop promising full oracle support. (Hopefully hpottinger's lastest email will help shake the bushes some)
[20:53] <PeterDietz> BioMed Central / Open Repositories is Oracle
[20:53] <hpottinger> I'm curious if it would be possible to make clear just what level of support for Oracle there is... would it be possible to move it out to a module?
[20:53] * hpottinger ducks
[20:53] <helix84> hpottinger: it's a DAO
[20:53] <helix84> DAOs
[20:53] <tdonohue> PeterDietz -- yea Open Repository uses Oracle...they just don't have a Committer any more to help support it
[20:54] <tdonohue> hpottinger -- nice duck!
[20:54] <tdonohue> yea, if we adopt DAOs we could pull Oracle out into a "module". Need someone to do that work though :)
[20:54] <DoctorLard> I haven't had a lot of time to explore the codebase, and naiive++, but Hibernate?
[20:55] <helix84> I think I've seen something like h2 DAO in the codebase, but it's definitely not production, more like a placeholder
[20:55] * scottatm_ (~scottatm@adhcp210.evans.tamu.edu) Quit (Quit: scottatm_)
[20:55] <hpottinger> I mean if it's mostly community-supported code, why not just move it out of the main code base, if it's possible, to make the contract clear
[20:56] <helix84> hpottinger: i don't agree here,
[20:56] <helix84> we currently have things set up so that they could be implemented with different storage backgrounds (probably even with solr),
[20:56] <tdonohue> Hibernate == definitely worth looking at. But, our main problem in the codebase right now is that the Oracle & Postgres support is really hardcoded in everywhere...not very easy to pull out unless we find volunteer(s) to work on making it happen
[20:57] <helix84> so it would be a step back to throw it out
[20:58] <helix84> what i'm saying is that it would be easier (for someone who knows it) to fix oracle than to throw out oracle completely
[20:59] <hpottinger> well... I'm just a tad grumpy, it's best if you all ignore me :-)
[20:59] <tdonohue> helix84 - yes, I agree. Easiest route would likely be to fix oracle support. But, longer term, I agree with others that it'd be nice if Oracle/Postgres were *both* modularized, so that both need not be 100% out of the box
[20:59] <helix84> tdonohue: what about Andrea and CILEA, they did some DAO work, was that just to support Solr or also Oracle?
[21:00] <tdonohue> i.e. if we just offered a "Postgres" module out-of-the-box, then we could find someone else to support the "Oracle" module...and maybe we'd find others wanting to support a "MySQL" module
[21:00] * helix84 shivers
[21:00] <tdonohue> my memory is not that good...you can ask Andrea/CILEA :)
[21:01] <helix84> I remember seeing some DAO work in the new JSPUI/Discovery code
[21:01] <helix84> I'll take a look if I'll remember
[21:01] <tdonohue> Ok...we're mostly going in circles here. We obviously need some Oracle Support help and need to see who out there is still using Oracle & willing to help with suppot
[21:02] <tdonohue> As time is essentially "out"...I do want to mention again that I'm going to be heading on holiday next week. I'll be out/offline from Dec 22 - Jan 2. So, I'll miss our next two scheduled mtgs -- Weds, Dec 26 & Weds Jan 2
[21:02] <helix84> I won't be here on the 26th, either, but I'll be here on the 2nd
[21:02] <tdonohue> You all are more than welcome to meet / see who shows up. Or we can just cancel
[21:03] <hpottinger> Oracle Vbox images with 11g on them: http://www.oracle.com/technetwork/community/developer-vm/index.html
[21:03] <kompewter> [ VirtualBox VMs for Developers ] - http://www.oracle.com/technetwork/community/developer-vm/index.html
[21:03] <tdonohue> Yea, I suspect many folks won't make the 26th meeting. The Jan 2nd meeting is likely to get better attendance.
[21:03] <hpottinger> I'll hop in to IRC on the 26th, just for grins
[21:03] <tdonohue> But, we can also just 'play it by ear'. If folks show up, you can talk about whatever you want to talk about :)
[21:04] <tdonohue> Also -- as noted, I'm likely to be offline during my break. So, if you email me, don't expect a response until after the new year :)
[21:05] <hpottinger> Play it by ear: +1
[21:07] <KevinVdV> Needs to run until next week guys
[21:07] <tdonohue> Sounds good then. Well, that's all the topics I had to bring up for today. I hope everyone has a happy holidays/new year!
[21:07] * KevinVdV (~KevinVdV@d54C154B1.access.telenet.be) Quit (Quit: HydraIRC -> http://www.hydrairc.com <- Go on, try it!)
[21:07] <helix84> I think Joao might still have something to say if you can still hang around
[21:07] <joaomelo> in fact i do have a problem with the current dspace-api
[21:07] <tdonohue> yep...I'm still here. I can hang around. Just no more "official" topics on our agenda
[21:08] <joaomelo> the development of springui requires us to break the current core
[21:08] <joaomelo> so there are 2 solutions: break, or develop a new dspace-api module (something like dspace-api2)
[21:08] <helix84> we didn't try to keep the API intact between major releases, did we?
[21:09] <tdonohue> we don't always do a good job of keeping our API (dspace-api) intact between major releases...we did change some things from 1.8 -> 3.0
[21:09] <helix84> tdonohue: would there be a problem with a more significant change? or is that expected?
[21:10] * scottatm_ (~scottatm@adhcp210.evans.tamu.edu) has joined #duraspace
[21:10] <tdonohue> A more significant change just really needs to be run by the Committers as a whole. Depends on the change
[21:10] <tdonohue> I'm just noting that we historically have "broken" (usually slightly broken) the dspace-api between major releases...
[21:11] <tdonohue> So, essentially we'd need to see a proposal for what the suggested significant changes are to the dspace-api...so that folks can comment on them and we can vote
[21:11] <joaomelo> using a DAO approach will break it
[21:12] <helix84> but still better to change the API than to maintain 2 APIs, no?
[21:12] <helix84> especially if new features would depend on the new one
[21:13] <tdonohue> +1 I'd say it's better to try to change the current API than create a new one. Changing the current API may be harder (cause you need approval of the committers & we need to fix all UIs as needed), but it'd be better over the long term than trying to maintain two separate APIs
[21:13] <helix84> hpottinger: ping?
[21:13] <helix84> PeterDietz: ping?
[21:13] <hpottinger> yup, still here, lurking
[21:14] <PeterDietz> I'm still here, I was reading over https://github.com/richardrodgers/mds
[21:14] <kompewter> [ richardrodgers/mds · GitHub ] - https://github.com/richardrodgers/mds
[21:14] <hpottinger> though, quite distracted by this shiny toy: http://pdfx.cs.man.ac.uk/
[21:14] <kompewter> [ pdfx: PDF to XML ] - http://pdfx.cs.man.ac.uk/
[21:14] <helix84> must... not... look...
[21:15] <helix84> slap! stay focused
[21:15] * tdonohue shines a light at hpottinger...hey look over here...shiny!
[21:15] <PeterDietz> ok, so what is the change the breaks that API.
[21:15] <hpottinger> helix84, you have my attention... I'll be needing a beverage soon, though
[21:16] <PeterDietz> I say we have full authority to break API between versions. Just make sure that clients are updated to the newer "contract"
[21:16] <hpottinger> and we have a whole year to deliberate it...
[21:17] <tdonohue> PeterDietz++ (I'd actually guess that we *usually* break small parts of the API between major versions)
[21:17] <helix84> like i said (off channel) - better to break the API now, early in the cycle
[21:17] <tdonohue> helix84++
[21:17] <PeterDietz> ..but saying "hey I have some random change that alters a decent amount of core code", before that PR gets merged into master, it should have a good reason, fix what it breaks, and get buy-in from others
[21:18] <PeterDietz> ...and that PR should also get Hardy, and myself, a drink...
[21:18] <hpottinger> PeterDietz++
[21:18] <joaomelo> maybe in the following weeks i could show a proposal
[21:18] * tdonohue is looking for the "buy a drink" option in GitHub...
[21:19] <joaomelo> our current DAO approach is here https://github.com/lyncode/DSpace/tree/springui/dspace-springui/src/main/java/org/dspace/orm
[21:19] <kompewter> [ DSpace/dspace-springui/src/main/java/org/dspace/orm at springui · lyncode/DSpace · GitHub ] - https://github.com/lyncode/DSpace/tree/springui/dspace-springui/src/main/java/org/dspace/orm
[21:19] <helix84> oooh, shinyyy ;)
[21:19] <tdonohue> joaomelo - that sounds that a good timeline for a proposal. We can even add it to a meeting agenda after the new year to kick off discussion on it
[21:19] * joaomelo (~DSpace@188.250.43.157) Quit (Read error: Connection reset by peer)
[21:20] <tdonohue> oooo...that is shiny! I think you're likely to get a lot of support for DAO work in the dspace-api (even if it breaks stuff initially)
[21:20] * joaomelo (~DSpace@188.250.43.157) has joined #duraspace
[21:20] <tdonohue> hmm...joaomelo seems to have fallen off...there he is
[21:21] <tdonohue> I just said:
[21:21] <tdonohue> (3:20:44 PM) tdonohue: oooo...that is shiny! I think you're likely to get a lot of support for DAO work in the dspace-api (even if it breaks stuff initially)
[21:21] <helix84> tdonohue: what he's asking us is to fix xmlui
[21:21] <helix84> i think kevin would be willing to help with that
[21:22] <joaomelo> and jspui
[21:22] <helix84> i thought you're good with jspui :)
[21:22] <tdonohue> well, you'd likely need to fix all other interfaces -- xmlui, jspui, oai, lni, swordv1, swordv2
[21:23] <helix84> oai is joao's child
[21:23] <tdonohue> again, that's not a huge problem, as long as the Committers approve of the dspace-api change...and as long as the change gets in EARLY (so we have time to fix all the necessary interfaces)
[21:23] <helix84> and didn't we want to exclude lni?
[21:24] <tdonohue> yea, but LNI still exists in 3.0. I had talked about that at one point, but it never happened
[21:24] <tdonohue> I was just listing *all* our DSpace interfaces for completeness...they'd all need possible fixing / testing
[21:24] <helix84> (i don't necessarily agree, just pointing that out)
[21:24] <joaomelo> +1 for excluding it
[21:24] <helix84> i think REST would make up for LNI
[21:25] <helix84> who was the main LNI user?
[21:25] <tdonohue> MIT (Sands & RichardR) uses LNI
[21:25] <tdonohue> So, likely they'd fix it if it got broken
[21:25] <PeterDietz> so.. I've never used Hibernate. I've got some questions about it
[21:26] <PeterDietz> but for starters, having to write all your own SQL, is an old paradigm, and the ORM/hibernate should handle that CRUD
[21:26] <tdonohue> Essentially, next steps are to: (1) get a proposal in front of the committers & discuss it (on email or mtg or both), (2) if it gets approved, try to get the code in early, (3) Then work with other Committers to fix each of our existing interfaces that'd need fixing
[21:27] <PeterDietz> regarding UI fixes. Without being TOO forward looking, I wonder if there is some type of non-complicated "business logic layer" plumbing we could put in place, so that changes like this to API don't affect UI
[21:28] <hpottinger> Business Logic Layer ++
[21:28] <helix84> well that's another thing that has been talked about for a long time - putting more business logic INTO the API and remove it from the UIs
[21:28] <helix84> so it seems an API change is in order anyway
[21:29] <tdonohue> yea...we've been talking several things that would require significant API changes...DAOs would, a Business Logic Layer would, etc.
[21:29] <helix84> and it seems there could potentially be a good deal of parallelization of that work, different people fixing different UIs :)
[21:29] <hpottinger> PeterDietz, what's your questions about Hibernate? I'm no expert, but it would guide my research
[21:29] <PeterDietz> I need to look at, and play with, MDS
[21:31] <tdonohue> helix84 -- yea, we definitely could do fixing in parallel. Again, I know many Committers have been wanting some form of DAOs for a long time...so, I suspect folks will be willing to chip in & help
[21:32] <hpottinger> This is an area of interest in particular for Robin Taylor, I believe
[21:33] <tdonohue> Robin Taylor is interested in DAOs, Mark Diggory is/was interested in DAOs, I am interested in DAOs, I suspect many others as well
[21:35] * helix84 has been having wet dreams about DAOs
[21:35] <helix84> no, not really :)
[21:35] <hpottinger> I am, in abstract, interested in them (see what I did there?) :-) Though, really, we're not going to be using Oracle for much longer
[21:36] <hpottinger> but, if we can off-load Oracle compatibility concerns, hooray!
[21:36] <helix84> i think it's about hibernate, too
[21:36] <helix84> or solr
[21:36] <tdonohue> hpottinger -- but DAOs will let you gracefully "exit" your role as DSpace Oracle Support Guy ;) - "Now you can support it yourself!"
[21:37] <hpottinger> tdonohue: didn't ask for the role, happy to be rid of it, let's get it done
[21:37] <tdonohue> no one ever asks for the DSpace Oracle Support Guy role...it just gets bestowed on the nearest person using DSpace + Oracle :)
[21:38] <hpottinger> and atmire is under contract to support DSpace on Oracle...
[21:42] <helix84> tdonohue: just before today's DevMtg Val has posted the minutes from yesterday's DCAT meeting about DC registry update, we should put it on the agenda so that we don't forget (in a few weeks).
[21:42] <tdonohue> helix84 -- from talking with Val, it sounds like DCAT is preparing a proposal for the Committers to review. I don't think that proposal is complete yet -- when it is, it will definitely go on our agenda
[22:00] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has left #duraspace
[22:21] * jonathangee (~jgreen@142.176.125.60) Quit (Quit: jonathangee)
[22:38] * jonathangee (~jgreen@blk-142-16-43.eastlink.ca) has joined #duraspace
[22:49] * jonathangee (~jgreen@blk-142-16-43.eastlink.ca) Quit (Ping timeout: 256 seconds)
[22:52] * tdonohue (~tdonohue@c-50-129-94-92.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[22:58] * DoctorLard (~johnno@9.109.124.202.static.snap.net.nz) has left #duraspace
[22:58] * helix84 (a@195.113.97.174) has left #duraspace
[23:04] * jonathangee (~jgreen@blk-142-16-43.eastlink.ca) has joined #duraspace
[23:06] * jonathangee (~jgreen@blk-142-16-43.eastlink.ca) Quit (Client Quit)
[23:14] * jonathangee (~jgreen@blk-142-16-43.eastlink.ca) has joined #duraspace
[23:19] * jonathangee (~jgreen@blk-142-16-43.eastlink.ca) Quit (Client Quit)
[23:21] * jonathangee (~jgreen@blk-142-16-43.eastlink.ca) has joined #duraspace
[23:28] * joaomelo (~DSpace@188.250.43.157) Quit (Ping timeout: 244 seconds)
[23:33] * jonathangee (~jgreen@blk-142-16-43.eastlink.ca) Quit (Quit: jonathangee)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.