Timestamps are in GMT/BST.
[6:46] -rajaniemi.freenode.net- *** Looking up your hostname...
[6:46] -rajaniemi.freenode.net- *** Checking Ident
[6:46] -rajaniemi.freenode.net- *** Found your hostname
[6:46] -rajaniemi.freenode.net- *** No Ident response
[6:46] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:46] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:46] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[13:50] * tdonohue (~tdonohue@c-50-129-94-92.hsd1.il.comcast.net) has joined #duraspace
[14:41] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[16:48] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has joined #duraspace
[17:48] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has left #duraspace
[19:48] * helix84 (a@195.113.97.174) has joined #duraspace
[19:49] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has joined #duraspace
[19:52] * bram-atmire (~bram@94-224-134-252.access.telenet.be) has joined #duraspace
[19:55] * KevinVdV (~KevinVdV@d54C154B1.access.telenet.be) has joined #duraspace
[19:57] <tdonohue> Hi all..reminder that we have our DSpace Devel Mtg starting in just a few minutes. https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-12-05
[19:57] <kompewter> [ DevMtg 2012-12-05 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-12-05
[20:00] <tdonohue> Hello all...welcome. It's now time for our weekly DSpace Developers Mtg.
[20:01] <tdonohue> The agenda is up at: https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-12-05
[20:01] <kompewter> [ DevMtg 2012-12-05 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-12-05
[20:01] <tdonohue> I also just realized that we should have reinstated our "JIRA reviews" this week...but, as I didn't come prepared for that...I guess we'll wait till next week
[20:02] <tdonohue> So...first off -- Congrats to everyone on 3.0! Great to get it out the door last week!
[20:02] <tdonohue> A huge kudos to the 3.0 Release Team (hpottinger, sands, helix84, robint), as I think they did a great job
[20:03] <mhwood> Seconded.
[20:03] <bram-atmire> cheers!
[20:03] <hpottinger> Thanks, I think it all worked out really well, and back at ya tdonohue.
[20:03] <hpottinger> likewise, thanks to mhwood for making us a maintenance branch
[20:03] * tdonohue wants to take a brief moment to remind everyone that if you have any ideas/brainstorms on how to make future releases go even better, feel free to start jotting them down or sending our way. This is not just for Release Team members, but anyone
[20:04] <tdonohue> oh, yea..and definitely thanks to mhwood -- even though he wasn't "officially" on RT, it seemed like he stepped in to help a lot
[20:04] * hpottinger thinks we should add mhwood to the team via time machine
[20:05] <tdonohue> and thanks to bram-atmire for his great Release Notes...basically, thanks to all. Good to have 3.0 out there :)
[20:06] <tdonohue> So, the first topic really on this agenda was just to touch back on 3.0. Anyone started any upgrades yet, or notice anything yet requiring attention/feedback? Or anything else to tidy up, post-3.0?
[20:06] <hpottinger> I'm still working on getting 3.0 running on Oracle...
[20:06] <helix84> let's not forget Kevin, the bug slayer
[20:07] <hpottinger> (and also working on IT to get us *away* from running on Oracle at all)
[20:07] <tdonohue> yep...KevinVdV was the bug-slayer :)
[20:07] <tdonohue> so, hpottinger -- you are still having issues with 3.0 on Oracle then?
[20:08] <hpottinger> tdonohue, yes, it's still complaining about missing column_id
[20:09] <tdonohue> ok, good to note (but bad to hear, obviously). I'm hoping we can get some other Oracle-folks to let us know of their success or failure as well...
[20:10] <tdonohue> Anyone else trying upgrades to 3.0 or have it scheduled?
[20:11] <helix84> yes, i've been running a staging server on master for a long time, but i'm planning to upgrade a production server in the following days
[20:13] <hpottinger> we're planning on upgrading to 3.0 asap, over the holidays, as soon as I can figure out the Oracle stuff
[20:13] <tdonohue> cool. Definitely would be interested to hear how it goes for both of you. (Sidenote: DuraSpace also sometimes likes to feature sights who are early-upgraders in a blog post or similar...so, anyone who does upgrade soon can feel free to get in touch if you want it publicized.)
[20:13] <tdonohue> s/sights/sites/
[20:13] <kompewter> tdonohue meant to say: cool. Definitely would be interested to hear how it goes for both of you. (Sidenote: DuraSpace also sometimes likes to feature sites who are early-upgraders in a blog post or similar...so, anyone who does upgrade soon can feel free to get in touch if you want it publicized.)
[20:14] <helix84> Ian Boston from Cambridge also seems to feel adventurous
[20:14] <helix84> one interesing tidbit is that they're dropping their dark archive patches and will do with just embargo
[20:15] <hpottinger> that *is* interesting...
[20:15] <tdonohue> yes it is.
[20:16] <helix84> which reminds me that making a part of DSpace into a dark archive has been a FAQ on -tech, but I always tell them to make 2 instances and hide one into the intranet
[20:17] <tdonohue> Ok. I think the next part of this topic is just to touch base on 3.1 thoughts. It seems like 3.1 will definitely happen, since we already have some minor bugs to resolve...just a matter of *when* we feel we have important-enough fixes to push out.
[20:17] <mhwood> I think that's the best way to go, until we've pulled authorization down into the business logic layer that we haven't done yet.
[20:18] <helix84> I still didn't notice almost any patches or commits for 3.1 :)
[20:18] <mhwood> Don't we already have one important to-be-fixed that was deferred to 3.1 due to time constraints?
[20:18] <helix84> But there is one patch for CC licenses in submission forms that is liiking for a reviewer. Anyone here using CC & submission workflow?
[20:19] <helix84> mhwood: note that I didn't say open issues, I said patches :)
[20:19] <mhwood> OK, CSV library replacement is awaiting patch.
[20:19] <hpottinger> speaking of CSV library, I think Richard Rodgers has played around with newer libraries in MDS
[20:20] <tdonohue> mhwood -- we did have bigger Item Versioning + AIP compatibility issues which were differed to 3.1. That's the one I can think of. But, admittedly, that work may take a while (month or so)...it's possible it also could be differed to 3.2/4.0, depending on how quick we need to push out 3.1.
[20:21] <helix84> tdonohue: do you have any proposals on how to change the AIP format, that we can discuss here? or do you plan to work it out just with mdiggory?
[20:21] <tdonohue> Oh, yea, and the CSV library issue (GPL license) was important for 3.1
[20:22] <tdonohue> helix84 -- I have no proposals, yet. Haven't gotten to it. I had some ideas bouncing around, but need time to put them to a wiki page & actually determine whether those ideas are *doable* in METS
[20:23] <tdonohue> so, essentially, it's on my to-do list
[20:23] <tdonohue> Is there anyone who is taking the lead on the CSV issue? DS-1407 I think that's one that would be very nice to ensure gets into 3.1
[20:24] <kompewter> [ https://jira.duraspace.org/browse/DS-1407 ] - [#DS-1407] Refactor SOLR Statistics to use OpenCSV or Apache Commons CSV - DuraSpace JIRA
[20:24] <tdonohue> Ds-1407 is the issue about us having a GPL dependency that we really shouldn't have in SOLR Stats
[20:25] <KevinVdV> I will take that one !
[20:25] <KevinVdV> Unless anbody objects ?
[20:25] <mhwood> No objection here; thanks!
[20:25] <tdonohue> Thanks KevinVdV -- feel free to claim it :) No objections from me, Mr. Bug-Slayer
[20:26] <helix84> KevinVdV: have you decided for one of those two suggested libraries?
[20:26] <KevinVdV> Haven't yet I will take a look at both soon
[20:27] <tdonohue> Of those two libraries, I'd recommend OpenCSV if possible, as it's also used in our DSpace Batch Metadata Processing.
[20:27] <tdonohue> (i.e. it'd be good to use one CSV library in DSpace, if we can...rather than multiple)
[20:27] <KevinVdV> Allright I will attempt to do OpenCSV first (no need in using new libs if old ones are present)
[20:28] <tdonohue> sounds good
[20:28] <KevinVdV> Logging this in the ticket so I don't forget ;-)
[20:29] <tdonohue> Anything else folks want to talk about with regards to 3.1? Right now, I'm assuming our schedule is still a bit flexible -- i.e. 3.1 isn't coming until we have something important enough to release.
[20:29] <helix84> anyone here using Shibboleth?
[20:29] <hpottinger> I am
[20:29] <helix84> hpottinger: DS-1410
[20:29] <kompewter> [ https://jira.duraspace.org/browse/DS-1410 ] - [#DS-1410] ShibbolethAuthentication has multiple NPE and Findbugs issues - DuraSpace JIRA
[20:30] <helix84> and really nobody uses CC licenses + submission forms? There's a patch and it's really simple, it just needs confirmation.
[20:31] <hpottinger> ah, we're not using Shib consortially, we have total control of what attributes are released
[20:31] <hpottinger> but I can see where 1410 would be a problem
[20:32] <helix84> hpottinger: could you "emulate" the missing headers just by ignoring them in the SP's Apache httpd?
[20:33] <tdonohue> A general 3.1 reminder. We do have a 'dspace-3_x' branch now in GitHub (https://github.com/DSpace/DSpace/tree/dspace-3_x). So, 3.1 Fixes need to be committed to that branch *AND* merged to master. "master" is now 4.0-SNAPSHOT
[20:33] <hpottinger> helix84: yep, can do that
[20:34] <helix84> tip: it's easy to do by commiting to either branch, then weitching to the other and doing "git cherry-pick [commit-hash]"
[20:34] <helix84> hpottinger: can you take the ticket, then?
[20:34] <helix84> s/weitching/switching/
[20:34] <kompewter> helix84 meant to say: tip: it's easy to do by commiting to either branch, then switching to the other and doing "git cherry-pick [commit-hash]"
[20:35] * tdonohue notes we should be putting these Git tips into our docs somewhere - I know I'm very good at forgetting such useful tips when I actually want to use them :)
[20:35] <bram-atmire> @tdonohue on this page? https://wiki.duraspace.org/display/DSPACE/Development+with+Git
[20:35] <kompewter> [ Development with Git - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Development+with+Git
[20:36] <helix84> i'll add it there
[20:36] <tdonohue> yea, likely that's the best place.
[20:36] <hpottinger> helix84, I've assigned 1410 to myself
[20:36] <helix84> you continue to push hardy to assign the bug ;)
[20:37] <tdonohue> One final note about 3.1 : We already have some bugs getting scheduled for 3.1. So, if you get some extra time in coming weeks/months, feel free to claim one and squash it: https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+resolution+%3D+Unresolved+AND+fixVersion+%3D+%223.1%22+ORDER+BY+priority+DESC&mode=hide
[20:37] <kompewter> [ Issue Navigator - DuraSpace JIRA ] - https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+resolution+%3D+Unresolved+AND+fixVersion+%3D+%223.1%22+ORDER+BY+priority+DESC&mode=hide
[20:38] <hpottinger> and if you're working on one (staring at myself right now) that doesn't have a Jira issue, and that starts to "bug" you at all, make a Jira issue for it :-)
[20:38] <tdonohue> +1 hpottinger
[20:39] <helix84> I thought Java has the incrementing operator
[20:39] <helix84> hpottinger++
[20:39] <tdonohue> Ok, I think that's all I have for 3.0 & 3.1 stuff for today. Looking forward to hearing about everyone's experiences in your upgrades in coming weeks/months
[20:39] <helix84> though if that increments hpottingers by one, I'm happy for that, too
[20:40] <hpottinger> as long as he works for me...
[20:40] <tdonohue> I think *one* hpottinger is plenty :)
[20:40] <tdonohue> Although...more hpottingers could mean more commits...hmmmm :)
[20:41] <hpottinger> not necessarily
[20:41] <tdonohue> true true
[20:41] <hpottinger> 2 more and I'd have a quorum
[20:42] <tdonohue> Ok. The last topic on the agenda is just to bring up the "DSpace Future Directions" meetings with DCAT & Committers from the last few weeks. I honestly think they went well, and thanks to all who were able to join
[20:42] <tdonohue> the notes are available publicly at: https://wiki.duraspace.org/pages/viewpage.action?pageId=33238592
[20:42] <kompewter> [ DCAT/Committer Meeting Notes - DSpace Futures (Nov 2012) - Community Groups - DuraSpace Wiki ] - https://wiki.duraspace.org/pages/viewpage.action?pageId=33238592
[20:42] <tdonohue> & DuraSpace will be sending out a more "formal" summary of topics discussed (likely in the next week or so)
[20:43] <hpottinger> wish I could have made it to meeting 2
[20:43] <tdonohue> But, a few big things that stuck out in my mind were...
[20:43] <tdonohue> 1. It seems like we have a lot of folks really wanting to use a REST API (or some sort of "repository abstraction layer"). This was feedback both from committers & non-committers
[20:44] <helix84> damn you, wysiwig wiki!
[20:44] <tdonohue> 2. There seemed to be a lot of interest (at least in meeting 2) on finding ways to collaborate more. Sharing code/ideas earlier & working together on projects
[20:45] <tdonohue> this "collaborate more" idea was NOT necessarily just limited to Committers...but rather finding ways to encourage *everyone* to share what they are working on more, so we can collaborate on common solutions to common problems
[20:45] <helix84> ad 1) I added a proposal to today's agenda
[20:46] <helix84> tdonohue: I've been prodding our local dspace guru to share his developments for a long time, but he keeps complaining that they're not useful to anybody else :)
[20:47] <bram-atmire> you are not the local dspace guru?
[20:47] <helix84> nah
[20:47] <mhwood> Maybe if more of us knew about them, we would see something to generalize.
[20:47] <hpottinger> world, spinning...
[20:48] <tdonohue> 3. One other thing that actually came up quite a bit -- DSpace needs to NOT try to do everything. We need to find ways to allow for plugins/modularization, so that we don't try to do too much. This came again both from Committers and also from DCAT members and non-technical folks.
[20:48] <helix84> Well he keeps piling workarounds, e.g. for storing journals whic don't fit very well into our collection/item/bitstream boxes. So we could put him out of his misery by fixing the design.
[20:49] <tdonohue> There were plenty of other brainstorms / ideas through the discussions (read those notes...I think we got them all captured there, at least at a higher level), but those were the ones that stuck out the most to me
[20:50] <helix84> those notes are actually surprisingly true to what was said, good job, Tim!
[20:50] * joaomelo (~DSpace@188.250.33.123) has joined #duraspace
[20:50] <helix84> hi Joao
[20:50] <joaomelo> hi helix
[20:50] <tdonohue> wasn't just me -- I'm not a "super note taker"... I did take notes, but the end result was a combination of what Jonathan, Val & I all captured in our notes :)
[20:51] <hpottinger> well, just to put it out there, we'll be working on testing REST-API (all the forks, too), we are in the middle of merging two repositories, and the repository we're working with has some itches that REST will help scratch
[20:52] <tdonohue> In any case, as helix84 noted a while back....in our agenda, it is noted that one "project" we likely need to work heavily on for 4.0 is actually getting a REST-API of some sorts in place
[20:52] <helix84> what do you think about my suggestion to merge the Wijiti REST API?
[20:52] <mhwood> Two types of (3): (a) replace our home-grown pluggable authentication with e.g. Spring Security; (b) make it easy for external streaming servers to read from the assetstore and work closely with the DSpace UIs.
[20:53] <tdonohue> one note about Wijiti vs. Hedtek. Hedtek (although read-only), has UNIT TESTS! That's a very nice bonus.
[20:53] <tdonohue> But, admittedly, I haven't done a thorough test or review of either Wijiti or Hedtek REST APIs. I think we should look closely at both though...
[20:53] <hpottinger> I like the HedTek forks focus on testing, and mhwood++
[20:54] <tdonohue> mhwood++ (uh-oh, are there now 3 mhwoods?)
[20:54] <mhwood> (c) replace the whole pluggability setup with Spring?
[20:54] <helix84> honestly, i haven't looked at Hedtek, read-only discouraged me.
[20:55] <tdonohue> helix84 -- there could be a place for read-only though. It is also possible to implement 2 REST APIs too, if we felt the need. Read-only (high performance) & Write (secured access)
[20:55] <helix84> that thought scares me
[20:55] <mhwood> Reads need security too. (mumble mumble business logic layer mumble)
[20:56] <hpottinger> read-only: safe for public re-use
[20:56] <hpottinger> business logic layer ++
[20:57] <tdonohue> It's worth noting that this is parallel to an idea that was talked about in the *first* DCAT/Committer meeting a few weeks back. We had several folks noting that DSpace has issues with scalability still. Stuart Lewis, Committer Emeritus, said he's always wondered why we try to do everything in *one* UI -- he wondered why not have an Access-only (high performance) UI and a separate Admin UI.
[20:58] <mhwood> Admin. probably doesn't need to look or feel exactly like access, but I don't see how we gain speed by splitting them.
[20:58] <hpottinger> Repository as a Service, like that idea a lot
[20:59] <tdonohue> I'm not stating that the Read-only/Access-only UI (or REST API) wouldn't still have security...just stating that this is one way to split up the tasks that need to be *highly scalable* (and could be served directly from Solr or similar) from the tasks that require direct DB writes
[20:59] <helix84> Joao? ;)
[20:59] <tdonohue> mhwood -- the speed gain is that you could make sure the access-only/read-only UI *never* does DB queries...you can have it's content highly-indexed in Solr for quick access
[21:00] <tdonohue> This is all a giant brainstorm -- I'm not suggesting we need to jump this route or anything. It was just a very interesting idea from Stuart Lewis
[21:01] <hpottinger> PeterDietz has a pretty cool little Play Framework client for the HedTek REST-API
[21:01] <PeterDietz> hi
[21:01] <helix84> tdonohue: i didn't learn one thing in the conference call - how does Fedora achieve that people from different organizations join to work on a common project?
[21:02] <helix84> hi PeterDietz!
[21:02] <helix84> PeterDietz: I worked with your ES recently and it looks very good
[21:02] <PeterDietz> Thank you. Once you get some data in it, then the magic happens
[21:02] <helix84> PeterDietz: needs work, but shows a lot of promise
[21:03] <helix84> when you have time, see the comments I put under the docs you wrote
[21:03] <PeterDietz> heh, time
[21:03] <mhwood> I've been looking at Fedora recently, and I think the answer is that they only talk about the community and you have to ask someone how it works! (OK, it's better than that, but it took me a while to find technical doco.)
[21:03] <joaomelo> I need to take a closer look, however REST APIs are always a nice feature
[21:03] * linux4u (~james@employed.library.emory.edu) Quit (Ping timeout: 250 seconds)
[21:03] <helix84> PeterDietz: I meant when you can't sleep because of baby crying :)
[21:03] <tdonohue> helix84 -- Fedora is a smaller community. They actually have similar issues to us around sharing common projects (or have in the past). But recently, several Fedora institutions (& service providers) basically started a grass-roots effort to rebuild Fedora. They "self organized" and are self-funding the work.
[21:04] <tdonohue> and by "self-organized & are self-funding the work", I mean that these institutions formed a Fedora Steering Committee, and all promised a certain percentage of development time (or actual money) towards rebuilding Fedora
[21:05] <tdonohue> I'm not sure if that answer the Fedora question or not :)
[21:05] <mhwood> Getting larger things done seems to start with realizing that some sites have common problems they could solve together. Which depends on realizing that our local problems might be common problems and talking about them.
[21:05] <tdonohue> +1 mhwood
[21:05] <helix84> I guess. We could use a rolemodel on how to get these things rolling.
[21:06] * hpottinger isn't sure what to make of the idea of a Fedora reboot
[21:07] <mhwood> New origin stories and costumes for everyone?
[21:07] <KevinVdV> *Needs to run*
[21:08] * KevinVdV (~KevinVdV@d54C154B1.access.telenet.be) Quit (Quit: HydraIRC -> http://www.hydrairc.com <- Go on, try it!)
[21:08] <hpottinger> mhwood: stop, my head is *really* spinning now :-)
[21:08] <PeterDietz> helix84: Thanks for the comments on the ES, last I saw it was the first 3 notes. This digs into the "room for improvement"
[21:08] <tdonohue> hpottinger -- why not? Fedora's also around 10 yrs old. To be honest though, I don't think it will be a complete "reboot" all at once...from my understanding they are carefully concentrating on reworking specific "parts" little by little
[21:08] <helix84> PeterDietz: will you mind if I do some minor work on it, like i18n? I'd hate to cause conflicts.
[21:08] <tdonohue> i.e. they are breaking Fedora into parts...reworking one part...then reworking the next...etc etc
[21:09] <hpottinger> tdonohue: it's their project, run by their community, they have to do what they have to do, I get that... just, there's a lot of projects that use Fedora as a backbone...
[21:09] <mhwood> Eh, as long as the contracts are honored, it still works.
[21:09] <tdonohue> hpottinger -- but, that's my point...the fact that they are reworking it piece by piece means they are *trying* to honor their contracts...so, stuff on top of Fedora may not need to change too much
[21:10] <tdonohue> (or at least, that's the *idea* that I've heard for what Fedora is doing...whether they achieve that is yet to be decided)
[21:10] <hpottinger> I understand the theory... :-) The practice is where the fun really begins
[21:10] <helix84> PeterDietz: another thing I want to make is make it respect the authorization.admin.* options
[21:10] <tdonohue> yep, I agree, hpottinger
[21:11] <tdonohue> Ok..in any case here. We don't have any more topics for today. I'm willing to stick around if anyone has anything else to discuss. But the "formal meeting" is over for today
[21:12] <hpottinger> besides REST-API, I think we're edging around the idea that AuthZ/AuthN needs some work
[21:12] <tdonohue> yea...I'd agree with that. AuthZ/AuthN would be nice to do some work on
[21:13] <tdonohue> Maybe we need to start a "4.0 Wishlist" :)
[21:13] <helix84> tdonohue: the idea to "outsource" AuthZ/N doesn't sound bad. Assuming what the outsourcee provides is better than what we have.
[21:14] <hpottinger> May go hand-in-hand with REST-API anyway
[21:15] <tdonohue> In general, I'd rather "find a library" than "build it ourselves". So, I fully agree we should look to find an AuthZ/N solution out there that will work for us.
[21:16] <tdonohue> The "build it ourselves" just ends up leading to "support it ourselves" and "fix it ourselves" and "blame ourselves for doing it wrong the first time"....much rather "outsource" much of that. ;)
[21:17] <mhwood> Something else to push out might be the workflow logic. It might get pushed right out of DSpace altogether and live on its own. I think that a lot of products need "people workflow management" but I never saw a general-purpose library for that stuff -- all the "workflow" libraries are for making machines talk to each other.
[21:17] <helix84> how about making what we have a library? the XmlWorkflow stuff?
[21:18] <mhwood> Actually we ought to start by looking at DSpace and asking what is our contribution to information management vs. what bits are something that others could do (possibly better).
[21:18] <tdonohue> mhwood -- yea, I agree with that statement
[21:18] <mhwood> The workflow *UI* belongs with DSpace. It's the modelling of objects and steps and signoffs and whatnot that could be exportable.
[21:19] <helix84> like packagers/crosswalks
[21:19] <tdonohue> Also, I think that's something Richard Rodgers has been "toying with" some in his "Modernized DSpace" (MDS) work....he's been looking at stuff to yank out of DSpace in favor of another's library/tool
[21:19] <hpottinger> sounds like rules engine stuff
[21:20] <helix84> I think there would be quite a lot of interest in a library that can convert between metadata formats and has quite good standards compliance, like we have
[21:20] <helix84> does Fedora do something in that area?
[21:21] <hpottinger> there's bibblio
[21:22] <hpottinger> https://code.google.com/p/biblio-transformation-engine/
[21:22] <helix84> this? http://drupal.org/project/biblio
[21:22] <kompewter> [ biblio-transformation-engine - A Java library for applying transformation workflows to bibliographic metadata - Google Project Hosting ] - https://code.google.com/p/biblio-transformation-engine/
[21:22] <kompewter> [ Bibliography Module | drupal.org ] - http://drupal.org/project/biblio
[21:22] <helix84> ah, that
[21:22] <helix84> I think that's what EKT used
[21:22] <hpottinger> yep, it's in DSpace 3.0
[21:22] <helix84> correction: developed :)
[21:23] * bram-atmire (~bram@94-224-134-252.access.telenet.be) Quit (Quit: bram-atmire)
[21:23] <hpottinger> jumping back to AuthZ/N, Fedora uses JAAS (http://en.wikipedia.org/wiki/Java_Authentication_and_Authorization_Service)
[21:25] <tdonohue> that could be worth looking at
[21:25] <hpottinger> and possibly helpful in the workflow abstraction: http://java-source.net/open-source/rule-engines
[21:25] <kompewter> [ Open Source Rule Engines in Java ] - http://java-source.net/open-source/rule-engines
[21:27] <helix84> One thing that we're not doing as well as we could and for which there might be a library is AuthZ with proper ACLs. The stuff we have is rather simplistic.
[21:27] <mhwood> helix84++
[21:27] <hpottinger> simplistic, and it breaks a lot
[21:28] <helix84> another FAQ: collection permissions are inherited only during submission. facepalm.
[21:28] <mhwood> Yes! People expect dynamic inheritance, but we don't do that.
[21:29] <hpottinger> ah, yes, and we have a tool that looks like it might help
[21:29] <hpottinger> but it doesn't
[21:30] <helix84> The longer I'm in DSpace the more I'm aware of it's defficiencies, to such extent that I'm wondering how is it possible that DSpace is so good and liked overall. Am I a one-man club?
[21:30] <tdonohue> all a good example of us "building something ourselves" (authn/z & ACLs) that we later "blame ourselves for doing it wrong the first time" :)
[21:30] <hpottinger> helix84: don't let it get to you, this is the way of it
[21:31] <helix84> hpottinger: hmm, like getting married?
[21:31] <hpottinger> DSpace is an amazing tool and does exactly what people who are in a position to make decisions about IRs want, right out of the box
[21:31] <mhwood> The developer community has gotten fairly good at fixing the superficial problems as they are noticed.
[21:32] <tdonohue> helix84 -- the reality here is twofold... (1) DSpace is & has been popular cause it meets a need (out of the box IR) that no other system does that well. (2) But, DSpace is now 10 years old, and full of a bit of "spaghetti-code"...it needs some extra love to help bring it up to modern standards
[21:32] <hpottinger> it's a good box to put stuff in, and gives you tools to noodle around with metadata right away
[21:32] <helix84> first of all, I wouldn't personally start wtih Java :D
[21:32] <helix84> (hpottinger++)++
[21:32] <mhwood> Under-use of OO, nonscalable stuff like pulling giant arrays out of the DBMS....
[21:33] <tdonohue> helix84 -- well, that's an argument (non-Java) for us to get a REST API in place...then folks could build non-Java UIs (or tools) on top
[21:33] <helix84> a giant metadatavalue table which I both hate and love...
[21:33] <hpottinger> relying on DBMS to do heavy lifting
[21:34] <mhwood> Hmmm, I don't get why people think DBMSs are slow. That usually means badly tuned or improperly indexed.
[21:34] <helix84> tdonohue: I do that already. What I meant is I can't fix these "deep" problems because Java isn't my lingua franca
[21:34] <mhwood> Heh, like Ruby is most definitely not mine....
[21:34] <helix84> mhwood: I know mine are :)
[21:35] <hpottinger> the thing about depending on your DBMS for anything other than holding stuff is, you make it really hard to support more than one DB
[21:35] <mhwood> A write-only DBMS?
[21:36] <helix84> hpottinger: more than one instance or more than one DBMS?
[21:36] <hpottinger> more than one DBMS (don't mind me, I'm just the Oracle guy, I'm full of complaints)
[21:38] <helix84> i have a suggestion
[21:38] <mhwood> Every once in a while I look at whether something like LiquiBase could help with portability across DBMSs but so far I haven't been clever enough.
[21:38] <helix84> how about all commiters writing what areas they planned to work on (for their organizations) in the next year and we can find common areas
[21:39] <tdonohue> I only think DBMSs are slow when compared to a highly tuned/indexed search engine (e.g. Solr / Elastic Search). DBMSs are great to store stuff...but when you want to find stuff quickly & filter your results...Solr/Elastic Search seem so much quicker than complex DB queries
[21:39] <mhwood> A good idea, but it would require that I know what they are going to ask for next. :-/
[21:39] <helix84> mhwood: good point :(
[21:39] <helix84> i only ever know what I should have done yesterday
[21:40] <hpottinger> sounds good, helix84... and mhwood, are you *really* all caught up?
[21:40] <tdonohue> again, we could however create a "4.0 Wishlist" -- i.e. capture much of what we've said here in a Wiki page... and advertise what stuff we'd *like* to see happen
[21:40] <mhwood> If Solr can do it, Postgres should be able to do it. I wonder why they haven't.
[21:41] <tdonohue> mhwood -- I don't disagree. Just noting from past experience, a finely tuned Solr has often seemed much quicker than a finely-tuned Postgres
[21:41] <helix84> mhwood: i don't think so, that sounds very narrow-minded. Like thinking ASCII is all there is.
[21:41] <hpottinger> I don't get to tune my DB... le sigh
[21:41] <mhwood> Well, there's alternate durable identifiers. And altmetrics.
[21:41] <tdonohue> but, then again, maybe I'm just better at tuning Solr over Postgres...who knows ;)
[21:42] <mhwood> I keep feeling that we've turned away from making DSpace do everything to making Solr do everything.
[21:42] <helix84> mhwood: solr has many filters and transformers both at indexing and at searching time that are very flexible
[21:43] <tdonohue> mhwood -- not really. I think there's a line there. No one is saying we get rid of Postgres
[21:43] <hpottinger> only thing I make Solr do is reboot every night :-)
[21:43] <PeterDietz> going back to where some mentioned self-funding. There are organizations that use DSpace that don't have the in-house capabilities to accomplish some big changes they want. They could contract with a Registered-Service-Provide, to build it. I had an idea for an idea-marketplace. Where University-of-Somewhere pledges $500 towards some feature. As ten organizations pledge that amount, a developer can win the bounty by implementing it
[21:43] <mhwood> Well, if we're talking about searching *text* then Solr or something like it would be my first choice. Pg has full-text stuff but it's non-ANSI and I've never looked at it and Oracle probably does it very differently.
[21:43] <helix84> hmm, kickstarter?
[21:43] <tdonohue> It's more that we are saying "Replace Lucene with Solr"...and finely tune Solr & build the UI against Solr. Data would still be in Postgres...it'd just be indexed/cached in Solr
[21:44] <hpottinger> ooh, PeterDietz++
[21:44] <hpottinger> it's like Andrea Schweer's "buy a feature" exercise, but with real money.
[21:46] <PeterDietz> great minds think alike then. I'm sure you'd want to have some central/community guidance too.
[21:46] <PeterDietz> Maybe like Google Summer of Code, but not limited to students
[21:46] * hpottinger is a financial guy, but thinks there may be value in having DuraSpace hold the money
[21:46] <hpottinger> s/is/is NOT/g
[21:46] <kompewter> hpottinger is NOT a financial guy, but thinks there may be value in having DuraSpace hold the money
[21:47] <PeterDietz> Did hpottinger just mention to us that HE is last weeks Missouri Powerball winner?
[21:47] <hpottinger> erm, no
[21:47] <PeterDietz> ohh. he "IS NOT"
[21:47] <helix84> but he IS LIKE
[21:48] <hpottinger> erm, no
[21:48] <tdonohue> hpottinger is most definitely not the powerball winner
[21:48] <tdonohue> s/not the/the/
[21:48] <kompewter> tdonohue meant to say: hpottinger is most definitely the powerball winner
[21:48] <tdonohue> look how quickly that changes!
[21:49] <PeterDietz> The artificial intelligence robots that will parse this log in the future will explode
[21:49] <hpottinger> kompewter, make me the powerball winner!
[21:49] <tdonohue> in any case...this is all an interesting idea. I worry about some of the risks here though...
[21:49] <tdonohue> 1) what happens if someone is "unhappy" with the results of their money?
[21:50] <hpottinger> terms of service: read 'em
[21:50] <tdonohue> 2) How many institutions are actually able to budget money in this way...by adding "bets" to various projects?
[21:50] <mhwood> Yup, that's what documented requirements are for.
[21:50] <helix84> 1) well they should be involved from design, through development to implementation! you can't jsut say that at the end, dammit!
[21:50] <mhwood> 2 is a very good question.
[21:50] <tdonohue> 3) How does a developer get chosen? what if there are multiple -- who is the "decider"?
[21:51] <hpottinger> developers are self-choosing
[21:51] <hpottinger> it's a bounty system, right?
[21:51] <hpottinger> don't care if there's another team, my team will beat them
[21:51] <tdonohue> right..but, if it's a big project for big money, then you might have 2+ developers all "self-choose" themselves
[21:52] <tdonohue> 4) There's also the question of where the money "sits" and how long it sits there (indefinitely?).
[21:53] <hpottinger> oh, sure, teams would have to charter and organize, and since the dev talent likely comes from the institutions anyway... likely the institutions would claim the "prize"
[21:53] <PeterDietz> maybe you can have the stakeholder/moneyholder choose who to "contract" with. i.e. We like @mire's bid for project X the best. We'll go with them...
[21:53] * tdonohue isn't trying to poke holes here...not trying to tear this idea down...just trying to ask some honest questions. If there's a way to make it work, I'd love it to happen
[21:53] <helix84> i don't think this is doable, I agree share tim's concern in points 2-4
[21:54] <helix84> s/doable/viable/
[21:54] <kompewter> helix84 meant to say: i don't think this is viable, I agree share tim's concern in points 2-4
[21:55] <PeterDietz> none-the-less. I'd be more than happy to not be using XMLUI next year. ;) I'd like to push on an idea of a frontend-UI that is a pleasure to develop in
[21:55] <hpottinger> wait.... why does it have to be real money?
[21:55] <mhwood> I worry that we might get more solutions that only solve one site's problem, and miss out on generalizing to solutions that would benefit many sites.
[21:56] <helix84> PeterDietz: Joao is already working on that
[21:56] <hpottinger> PeterDietz++
[21:56] <tdonohue> Out of the various "DSpace Futures" meeting there were several folks who gave the *impression* that they'd like to develop a new UI...but, they are waiting on a stable REST API to do so
[21:57] <mhwood> Yeah, I think there are a lot of sites thinking "we would do X if only we had the resources", sitting on tasty ideas that others would like to make and use too.
[21:58] <hpottinger> tasty ideas are the currency I want to trade
[21:58] <tdonohue> At least a few institutions mentioned they were dissatisfied with the current UIs, but that they didn't have a way to build their own without an enormous amount of complexity....they all were asking for a "common repository interface" or REST API of some sort
[21:58] <helix84> joao is lurking here, so try asking him
[21:58] * linux4u (~james@employed.library.emory.edu) has joined #duraspace
[21:58] <tdonohue> hpottinger will trade his tasty idea for a implementation to be named later
[21:59] <hpottinger> Tuesday
[21:59] <mhwood> You only have to pay people to do things they don't want to do.
[21:59] <tdonohue> haha..yea, tuesday.. I forgot that part
[21:59] <mhwood> ...or can't afford to do.
[21:59] * hpottinger also has a shortage of tasty ideas...
[22:00] <hpottinger> but, maybe "buy a feature" is a useful exercise, anyway, even if the money isn't real
[22:01] <tdonohue> "buy a feature" is a willingness to put resources (money, developer time, feedback) toward something.
[22:01] <tdonohue> and resources are what we need to make common projects happen
[22:01] <mhwood> REST: yes, we keep coming back to the point that, although DSpace should continue to be useful out-of-the-box, it would be considerably more useful if it also provided a platform for other stuff.
[22:02] <hpottinger> give each sponsor a "budget" based on the dev hours they pony up, and let everyone put "money" behind what they think is most important
[22:02] <hpottinger> we did that here, the winner was "streaming"
[22:03] <tdonohue> giving each sponsor a "budget" is an interesting idea...
[22:06] <tdonohue> not sure how that'd work, and it'd likely involve having to raise sponsorship amounts (or ask for additional money in some other way), since this is budgeting for extra stuff to happen
[22:06] <tdonohue> but, it's a nice brainstorm
[22:06] <hpottinger> tdonohue: ask Andrea about her buy a feature exercise, she got the script from some place online
[22:07] <hpottinger> oh, well, there it is, top hit on Google: http://innovationgames.com/buy-a-feature/
[22:07] <kompewter> [ Buy a Feature | Innovation Games ] - http://innovationgames.com/buy-a-feature/
[22:08] <tdonohue> huh...cool
[22:08] <mhwood> Sorry, got to go.
[22:09] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[22:18] <hpottinger> but, really, if we want to see a new UI, it sounds like the best way to "buy" that is to finish up REST-API
[22:25] <hpottinger> have to go...
[22:25] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has left #duraspace
[22:50] * tdonohue (~tdonohue@c-50-129-94-92.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[23:53] * linux4u (~james@employed.library.emory.edu) Quit (Ping timeout: 260 seconds)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.