Timestamps are in GMT/BST.
[6:36] -rajaniemi.freenode.net- *** Looking up your hostname...
[6:36] -rajaniemi.freenode.net- *** Checking Ident
[6:36] -rajaniemi.freenode.net- *** Found your hostname
[6:36] -rajaniemi.freenode.net- *** No Ident response
[6:37] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:37] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:37] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[9:52] * fasseg (~fas@HSI-KBW-078-043-007-220.hsi4.kabel-badenwuerttemberg.de) has joined #duraspace
[11:51] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[12:51] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) has joined #duraspace
[13:05] * kompewter (~kompewter@ec2-50-17-201-82.compute-1.amazonaws.com) Quit (Ping timeout: 246 seconds)
[13:07] * kompewter (~kompewter@ec2-50-17-201-82.compute-1.amazonaws.com) has joined #duraspace
[13:09] * jonathangee (~jonathang@blk-222-249-31.eastlink.ca) Quit (Remote host closed the connection)
[13:17] * jonathangee (~jonathang@blk-222-249-31.eastlink.ca) has joined #duraspace
[13:30] * ruebot (~ruebot@pdpc/supporter/professional/ruebot) Quit (*.net *.split)
[13:30] * ChanServ (ChanServ@services.) Quit (*.net *.split)
[13:34] * ruebot_ (~ruebot@50.112.50.181) has joined #duraspace
[13:34] * ruebot__ (~ruebot@ec2-50-112-50-181.us-west-2.compute.amazonaws.com) has joined #duraspace
[13:34] * ruebot__ (~ruebot@ec2-50-112-50-181.us-west-2.compute.amazonaws.com) Quit (Client Quit)
[13:34] * ruebot_ (~ruebot@50.112.50.181) Quit (Ping timeout: 260 seconds)
[13:34] * ruebot_ (~ruebot@ec2-50-112-50-181.us-west-2.compute.amazonaws.com) has joined #duraspace
[13:34] * ruebot_ (~ruebot@ec2-50-112-50-181.us-west-2.compute.amazonaws.com) Quit (Client Quit)
[13:37] -tomaw- [Global Notice] Hi, yes NickServ, ChanServ etc are gone - we're investigating why right now.
[13:40] * misilot (~misilot@p-body.lib.fit.edu) Quit (Ping timeout: 256 seconds)
[13:41] * misilot (~misilot@p-body.lib.fit.edu) has joined #duraspace
[13:47] * ChanServ (ChanServ@services.) has joined #duraspace
[14:36] * misilot (~misilot@p-body.lib.fit.edu) Quit (*.net *.split)
[14:48] * misilot1 (~misilot@p-body.lib.fit.edu) has joined #duraspace
[14:55] * ruebot (~ruebot@ec2-50-112-50-181.us-west-2.compute.amazonaws.com) has joined #duraspace
[14:55] * ruebot (~ruebot@ec2-50-112-50-181.us-west-2.compute.amazonaws.com) Quit (Changing host)
[14:55] * ruebot (~ruebot@pdpc/supporter/professional/ruebot) has joined #duraspace
[15:00] * fasseg (~fas@HSI-KBW-078-043-007-220.hsi4.kabel-badenwuerttemberg.de) Quit (*.net *.split)
[15:25] * misilot1 (~misilot@p-body.lib.fit.edu) Quit (Ping timeout: 245 seconds)
[15:27] * misilot1 (~misilot@p-body.lib.fit.edu) has joined #duraspace
[15:29] * fasseg (~fas@HSI-KBW-078-043-007-220.hsi4.kabel-badenwuerttemberg.de) has joined #duraspace
[15:40] * misilot1 (~misilot@p-body.lib.fit.edu) Quit (Ping timeout: 256 seconds)
[15:41] * ruebot (~ruebot@pdpc/supporter/professional/ruebot) Quit (Ping timeout: 256 seconds)
[15:41] * ruebot (~ruebot@ec2-50-112-50-181.us-west-2.compute.amazonaws.com) has joined #duraspace
[15:41] * ruebot (~ruebot@ec2-50-112-50-181.us-west-2.compute.amazonaws.com) Quit (Changing host)
[15:41] * ruebot (~ruebot@pdpc/supporter/professional/ruebot) has joined #duraspace
[15:42] * misilot1 (~misilot@p-body.lib.fit.edu) has joined #duraspace
[15:46] * ruebot (~ruebot@pdpc/supporter/professional/ruebot) Quit (Quit: Please, sir, I want some more.)
[15:54] * ruebot (~ruebot@ec2-50-112-50-181.us-west-2.compute.amazonaws.com) has joined #duraspace
[15:54] * ruebot (~ruebot@ec2-50-112-50-181.us-west-2.compute.amazonaws.com) Quit (Changing host)
[15:54] * ruebot (~ruebot@pdpc/supporter/professional/ruebot) has joined #duraspace
[16:00] -christel- [Global Notice] Welcome to Splitville, Population: Shrinking -- as you may have noticed the network is suffering under the strain of yet another DDoS attack, we are working with our sponsors to try curb what we can and apologise for the inconvenience.
[16:31] * misilot1 is now known as misilot
[17:00] * kshepherd (kim@ec2-184-73-177-234.compute-1.amazonaws.com) has joined #duraspace
[17:05] * kshepher1 (kim@ec2-184-73-177-234.compute-1.amazonaws.com) Quit (*.net *.split)
[17:05] * awoods (~awoods@c-67-165-245-76.hsd1.co.comcast.net) Quit (*.net *.split)
[17:05] * ruebot (~ruebot@pdpc/supporter/professional/ruebot) Quit (*.net *.split)
[17:08] * ruebot (~ruebot@pdpc/supporter/professional/ruebot) has joined #duraspace
[17:12] * awoods (~awoods@c-67-165-245-76.hsd1.co.comcast.net) has joined #duraspace
[17:33] * jonathangee (~jonathang@blk-222-249-31.eastlink.ca) Quit (Remote host closed the connection)
[18:04] * PeterDietz (~peterdiet@128.146.173.70) has joined #duraspace
[18:58] * helix84 (~a@ip4-95-82-147-170.cust.nbox.cz) has joined #duraspace
[19:07] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has joined #duraspace
[19:28] * misilot1 (~misilot@p-body.lib.fit.edu) has joined #duraspace
[19:30] * misilot (~misilot@p-body.lib.fit.edu) Quit (Ping timeout: 256 seconds)
[19:57] * misilot1 is now known as misilot
[20:00] * robint (522a6b02@gateway/web/freenode/ip.82.42.107.2) has joined #duraspace
[20:00] <tdonohue> Hi all. Time for DSpace Developers Mtg. Agenda for today: https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-06-05
[20:00] <kompewter> [ DevMtg 2013-06-05 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-06-05
[20:01] <tdonohue> It's mostly an "open discussion" meeting today, as I didn't have any real suggested topics. But, we'll kick things off here with some Pull Request reviews
[20:01] <tdonohue> 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'll start at #185: https://github.com/DSpace/DSpace/pull/185
[20:01] <kompewter> [ fix hardcoded db name in dspace-info.pl by helix84 · Pull Request #185 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/185
[20:02] * PeterDietz (~peterdiet@128.146.173.70) Quit (*.net *.split)
[20:02] <tdonohue> argh, it's our lone perl script
[20:03] <mhwood> The fix itself seems right. I rambled on about all the other things that need fixed in it, but this one is good.
[20:03] <tdonohue> Do folks use this script? I'm fine with this PR, as long as folks use it. But, if no one really uses 'dspace-info.pl', I'd question whether we should even be shipping it with DSpace
[20:03] <helix84> tdonohue: no worries, thanks to mhwood, we already started piece-meal work on replacing it
[20:04] <helix84> tdonohue: I think we should keep it before we have a replacement
[20:04] <helix84> if for nothing else, then for inspiration what the replacement should do
[20:04] <mhwood> It's already got one vote.
[20:05] <helix84> btw this is a fix, so i really should have merged it
[20:05] <tdonohue> ok, well, then go ahead and merge in the fix. It seems obvious enough. My only question was whether we should even have this script around (but I agree, it seems useful in some ways, so we might as well keep until we can replace it)
[20:06] <helix84> done
[20:06] <tdonohue> next up #186 https://github.com/DSpace/DSpace/pull/186
[20:06] <kompewter> [ CAS authentication by misilot · Pull Request #186 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/186
[20:07] <helix84> ah, yes, good old CAS
[20:07] <helix84> it still doesn't have full functionality (getting attributes) and I think there are 2 implementations
[20:07] <tdonohue> ok, so, it's still a "work in progress"
[20:07] <misilot> https://github.com/DSpace/DSpace/pull/222 may better work ... but still no attributes either I believe
[20:07] <kompewter> [ Implementation of CAS (Single Sign-On) authentication for DSpace by nkneumann · Pull Request #222 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/222
[20:07] <tdonohue> One comment here: This needs a JIRA ticket
[20:08] * PeterDietz (~peterdiet@128.146.173.70) has joined #duraspace
[20:08] <tdonohue> (Or at least, I don't see a CAS JIRA ticket...maybe I'm overlooking it)
[20:08] <helix84> DS-1476
[20:08] <kompewter> [ https://jira.duraspace.org/browse/DS-1476 ] - [#DS-1476] CAS Authentication - DuraSpace JIRA
[20:08] <tdonohue> oh, thanks!
[20:08] <mhwood> I should give this some more attention, as we would *like* to be using CAS. (I even have Yet Another Implementation to deal with the hacked CAS at IU.)
[20:08] <helix84> we also have DS-1028 (mhwood)
[20:08] <kompewter> [ https://jira.duraspace.org/browse/DS-1028 ] - [#DS-1028] Single Sign-On CAS plugin for Dspace 1.7.2 - DuraSpace JIRA
[20:09] <tdonohue> so, misilot, is there a recommended pull to look at here (for those interested)? #186 or #222?
[20:09] <misilot> tdonohue: i haven't had time to work on mine, or test/really look at #222 (to see what's different and such)
[20:09] <helix84> I think we need to consolidate on a single version and test it (all of us participating in those tickets/pull requests)
[20:10] * PeterDietz (~peterdiet@128.146.173.70) Quit ()
[20:10] <tdonohue> oh, ok. got it, misilot. I thought you were recommending one over the other :)
[20:10] <misilot> not yet
[20:10] <misilot> :(
[20:10] * PeterDietz (~peterdiet@128.146.173.70) has joined #duraspace
[20:11] <tdonohue> +1 on trying to consolidate the work/implementation, if possible. Or at least perhaps pulling together common use cases to build from
[20:11] <tdonohue> also +1 to the CAS work in general. I think others would be interested in seeing it in DSpace
[20:11] <PeterDietz> hello, I've recovered from net/split
[20:12] <mhwood> I just wrote myself a big note to dig into these.
[20:12] <tdonohue> so, currently we have two CAS Jira tickets (1028 & 1476) and two PRs (186 & 222). Anyone willing to try to help pull this all together, to at least make everyone aware of the various interest?
[20:13] <helix84> I marked 1476 as "duplicates 1028"
[20:13] <tdonohue> (would like to at least see consolidation into a single JIRA ticket.... then we can look at the two PRs and see if theres commonality there)
[20:13] <tdonohue> ok, cool. sounds great, helix84
[20:14] * l_a_p (~chatzilla@93.49.188.236) has joined #duraspace
[20:14] <helix84> also adding the second PR to the first ticket
[20:14] <hpottinger> sorry, was distracted by other conversations, including #dspace... totally missed this meeting starting up :-)
[20:14] <tdonohue> Let's do one more for today: PR #188 https://github.com/DSpace/DSpace/pull/188
[20:14] <kompewter> [ DS-1485 fix for the Mirage theme by helix84 · Pull Request #188 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/188
[20:15] <tdonohue> related to DS-1485
[20:15] <kompewter> [ https://jira.duraspace.org/browse/DS-1485 ] - [#DS-1485] bitstream access icon alt text empty when bitstream has no permissions - DuraSpace JIRA
[20:16] * bollini (~chatzilla@host139-236-dynamic.42-79-r.retail.telecomitalia.it) has joined #duraspace
[20:16] <tdonohue> so, 188 sounds like it just needs to be implemented for all themes, helix84. Is that something you plan to do, or do you need help on it?
[20:17] <helix84> tdonohue: i plan to test it/them
[20:17] <helix84> oh, sorry, I was still talking about CAS
[20:18] <mhwood> I remember looking at 188, thinking it seemed reasonable, but unsure whether I'm a good enough judge of XSL-T to speak up.
[20:19] <helix84> I just made it for one theme so that someone can test and confirm
[20:19] <helix84> but sure, help is appreciated since this should be easy
[20:19] <helix84> misilot: would you care helping?
[20:20] <misilot> helix84: with which one sorry?
[20:20] <helix84> so for now it's incomplete, we can move on
[20:20] <helix84> misilot: DS-1485
[20:20] <kompewter> [ https://jira.duraspace.org/browse/DS-1485 ] - [#DS-1485] bitstream access icon alt text empty when bitstream has no permissions - DuraSpace JIRA
[20:21] <tdonohue> We'll stop there for today anyhow. That was the last PR for today. So, I can pause here a moment, if there's confusion
[20:23] <tdonohue> So, today is essentially and "open meeting" anyways. The only other topic I had on the agenda was to talk about 4.0 planning. But, if there are more pressing things to discuss, please feel free to let me know
[20:24] <tdonohue> Regarding 4.0, I mostly wanted to encourage us to think more about timelines & put out another call for folks interested in joining the Release Team. It'd be nice to get 4.0 timelines roughed out before OR13, if we can
[20:24] <hpottinger> scrolling back, I see we talked a bit about the dspace-info.pl script. I had a nutty idea about that the other day, what if we replaced it with a Groovy script?
[20:24] <helix84> why not jython?
[20:25] <mhwood> Why not REST?
[20:25] <helix84> my point being, either we go java all the way or we go back to accepting any language
[20:26] <tdonohue> helix84++ I'd rather we stick with Java since everything else is Java right now. REST is an option though, as would be even a shell script (though maybe not as easy to implement)
[20:27] <hpottinger> Jython, Groovy, doesn't matter to me really, and "any language" is a far cry from "including some jar files so we can write a simple script and still use our configuration system"
[20:27] <tdonohue> I'm not against doing things in other languages though -- we just haven't "standardized" on anything else besides Java.
[20:28] <PeterDietz> It looks like good fodder for a /site REST endpoint to me
[20:28] <mhwood> Where's my RPG III book...?
[20:28] <hpottinger> could port most of it to mhwood's DS-552 servlet
[20:28] <tdonohue> Groovy / Jython both run on a JVM though, so, I guess either isn't that far of a stretch anyhow. They are both closer than "perl"
[20:28] <kompewter> [ https://jira.duraspace.org/browse/DS-552 ] - [#DS-552] Servlet to deliver repository size statistics - DuraSpace JIRA
[20:29] <helix84> apropos, this is related to something i took up with Tim today
[20:29] <helix84> remember we have a "Who uses DSpace" section at dspace.org?
[20:30] <helix84> people submit that information manually (dspace version, interface, which features they use), which is a pain in the nect both for us and the dspace.org maintainer
[20:30] <tdonohue> http://www.dspace.org/whos-using-dspace
[20:30] <kompewter> [ DSPACE :: Forms Dashboard - www.dspace.org ] - http://www.dspace.org/whos-using-dspace
[20:30] <PeterDietz> I like this servlet.. http://kb.osu.edu/dspace/content-statistics
[20:30] <helix84> my suggestion was that we could provide an option upon DSpace installation (or even at any time) to send this information to dspace.org
[20:30] <helix84> for that, we need to gather it, first
[20:31] <helix84> which is what these statistics and version features do
[20:31] <helix84> thanks to mhwood!
[20:31] <mhwood> You're welcome!
[20:32] <mhwood> Or how about just letting people register base URLs and the site can sample them from time to time?
[20:32] <helix84> yep, that was the idea. give users the option to expose this information about their repository.
[20:32] <helix84> plus announce it to dspace.org
[20:32] <PeterDietz> ROAR harvests you: http://roar.eprints.org/950/
[20:32] <kompewter> [ Ohio State University: Knowledge Bank - Registry of Open Access Repositories ] - http://roar.eprints.org/950/
[20:33] <helix84> I'll make an ubmrella ticket for this feature
[20:33] <tdonohue> ROAR is ok. But, it's not "fine grained" around what version of DSpace you are running & which UI you are using (both of which are very important data points)
[20:34] <hpottinger> would now be a good time to point out we're already using Groovy? https://github.com/DSpace/DSpace/pull/30
[20:34] <kompewter> [ DS-1198 : Fix for "Unit Testing Framework fails to initialize properly on Windows OS" by tdonohue · Pull Request #30 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/30
[20:35] <tdonohue> oh, hpottinger. you had to pull that out :)
[20:35] <tdonohue> ok. hpottinger: you have my blessing to rewrite that script in Groovy :)
[20:35] <hpottinger> on my list
[20:36] <helix84> does that mean gmaven-plugin already pulls groovy?
[20:37] <tdonohue> I'm not sure that Groovy actually gets installed into DSpace. But, gmaven-plugin work is an example of a place where we (I) used Groovy during our build process
[20:38] <mhwood> Maven probably ought to have a more general plugin for dealing with local path syntax issues.
[20:39] <hpottinger> it's a good point of clarification, helix84, I was merely pointing out that we've already crossed the "only Java" line, not that we're set to use Groovy scripts.
[20:39] <mhwood> Meanwhile, I think part of the problem with the existing script is that it does too much and doesn't ask enough of things (running DSpace, running DBMS) that already understand what they are doing.
[20:39] <helix84> i'll take advantage of this multilanguage-open atmosphere to inquire - would you be fine if I contributed some stuff I made in Jython to DSpace?
[20:39] <tdonohue> In any case though, I agree with the general "thread" of this discussion to look towards making this info available via a UI (or even REST)
[20:40] <helix84> mhwood++
[20:40] <helix84> tdonohue: just let me point out that it can't be just one of the UIs - what UI is used is one of the important things being reported
[20:42] <tdonohue> RE: Groovy v. Jython v. JRuby v. whatever. I'd rather we try and "standardize" on a particular dynamic language for this sorta stuff. Ideally, we wouldn't be doing much in any of these languages though (unless we built an entirely new UI based in one of them), and seek instead to make more of this info available from the UI. A common complaint is that too much in DSpace is still commandline only.
[20:42] <mhwood> "Which UI(s) used" is difficult.
[20:42] <tdonohue> helix84: yea, sorry. Didn't mean "a UI" meaning *one* UI. Just meant that these stats are useful to surface in the UI, if we can.
[20:43] <robint> I'm generally in favour of using JVM based scripting languages, but agree with tdonohue that we want to avoid a proliferation of languages
[20:43] <mhwood> You'd have to ask the container, and know how to recognize what you are looking for. And be *able* to ask the container.
[20:43] <tdonohue> +1 to JVM based scripting languages
[20:44] <helix84> tdonohue: since you mentioned it, developing a new UI in jython was one of my wilder ideas
[20:44] <mhwood> I will suggest more plainly that if we have to script it, we may not be thinking about the problem properly.
[20:44] <mhwood> It is a question that should always be asked.
[20:44] <tdonohue> mhwood++
[20:45] <hpottinger> mhwood is probably on to something, though novel solutions are sometimes found by people "not thinking properly"
[20:45] <helix84> i was thinking more along the way that scripting gives you a rapid way to iterate, because the build-deploy-restart cycle of DSpace is simply way too long
[20:45] <mhwood> Depends on how many hundred JARs you have to drag in.
[20:45] <PeterDietz> Whats the intent of knowing someone's UI? Knowing how popular that UI is? If you want the content, you can probably get access to their OAI, or perhaps some future rest-bulk-extract endpoint, or just their URL to homepage
[20:46] <helix84> so it lets you develop quickly some things that can be *eventualy* replaced by pure java. the question then is if we do allow any (JVM-based) scripting language in the DSpace source we're distributing or only pure Java?
[20:46] <hpottinger> scripting is a nice fit for reporting, especially in the use case of "my repo manager wants to know these stats, to keep our library director happy"
[20:47] <PeterDietz> I want to allow any language UI. (So long as it know how to consume the DSpace REST API)
[20:47] <mhwood> Well, if we're scripting for prototyping, that's different.
[20:47] <helix84> PeterDietz: the "Who's using DSpace" page is actually immensely popular. It lets you filter by version, UI and features, so you can look at different existing repositories when you're deciding whether you want DSpace or a new feature in DSpace.
[20:48] <mhwood> hpottinger: consider where is the optimum partition between the report generator and the thing reported on. A tiny script that yanks out some XML or JSON seems right to me. The gathering of the raw info. belongs to the thing reported on, I think.
[20:48] <tdonohue> PeterDietz: Folks use that "Who's using Dspace" page to also find examples of DSpace sites they want to replicate. As we have multiple UIs, it's important to them to also understand who is using which UI. We also do want to have an understanding though of how popular a UI is overall
[20:49] <helix84> mhwood: on the other hand, what if it's not prototyping? would you allow, e.g. a Django UI?
[20:49] <hpottinger> mhwood: as long as the barrier to generating the info needed is low enough, that works, but when you're in a shop full of script-writing librarians...
[20:50] <mhwood> I don't think I'm in a position to allow or forbid. I would suggest that we already ship stuff "in the box" that maybe should migrate to add-on status.
[20:50] <tdonohue> RE: new UIs. I think it's fair game to build a new UI in *any* language. I'd be all for a new UI being built. However, just because it's built, does NOT necessarily mean it becomes "out of the box" (or default)
[20:51] <tdonohue> Currently, as (nearly) everything is Java, we are "standardizing" on that (and perhaps some stuff that can run on JVM).
[20:51] <hpottinger> I would also urge that whether it goes in the box should present very little barrier to a thing being built. If it's cool enough, you'll build it.
[20:51] <tdonohue> However, if in the future, there was an amazing Ruby on Rails (or whatever) UI built, that we felt should be the "Default UI", then we can change our minds at any time. None of these decisions are forever
[20:53] <helix84> I hope we can agree to say what's fine and what isn't - because allowing one JVM scripting language while not allowing another just feels wrong to me. So I hope we can say let's just have pure Java or let's have any of them.
[20:53] <tdonohue> The one thing I will push back on though. We cannot continue to "add another UI". Ideally, at some point, we need to standardize on a *single* out-of-the-box UI. There can still be third-party-supported UIs out there...but, it's too much to ask the Committers to support/sync many UIs at once
[20:54] <mhwood> tdonohue++
[20:54] <mhwood> N-1 UIs is one of the things I would "plug out" of DSpace, so long as we didn't lose them altogether.
[20:55] <mhwood> We don't even have to ship the coolest UI in-the-box. We just need one that works well.
[20:56] <tdonohue> helix84: I think what is "acceptable" is still up for grabs. Admittedly, my comments on Groovy were a bit "tongue in cheek". Ideally, we "standardize" on Java & one JVM-based scripting language (TBD) though... keeping us at one scripting language just makes it easier to maintain.
[20:56] <PeterDietz> Sorry to potentially change topic. But does anyone have any insight on kicking robots out of your statistics?
[20:57] <bollini> we need a UI that is easy to extend... the most cool plugin are probably related to UI features
[20:57] <PeterDietz> googlebot, fastsearch, yandex, ask, shorty...soton.ac.uk, scoutjetm, ask, discoveryengine to name a few are in our statistics data
[20:58] <hpottinger> I think curation scripts are a special case, pretty much "anything goes" for that use case, if you prefer a different scripting language, use it
[20:58] <mhwood> I need to get back to robot exclusion. I'm supposed to be working on by-agent exclusion.
[20:59] <helix84> to clarify one of the things i'm offering here in jython - the UI was only for the sake of discussion and it's clear that we don't want UI proliferation - but I can add a new kind of importer which I can pretty much guarantee would be quite popular. I'm not saying it's not possible to do it in Java, only I can't do it and I already have it working in Jython.
[20:59] <hpottinger> "our statistics data" could mean Solr, ES, or something else...
[20:59] <tdonohue> hpottinger ++ Yes, to be clear, you are more than welcome to create curation scripts (or even add-on modules) using different scripting languages. But, the "out-of-the-box" DSpace should try and simplify to one main scripting language
[20:59] <mhwood> DS-790
[20:59] <kompewter> [ https://jira.duraspace.org/browse/DS-790 ] - [#DS-790] SOLR - Spider detection to match on hostname or useragent - DuraSpace JIRA
[21:00] <PeterDietz> by statistics, i mean ElasticSearch usage statistics, but our robot determination process is exactly the same as SOLR.. Its sadly limited to a static list of ip addresses
[21:00] <bollini> some week ago we have said that stakeholder will be happy to see a more "modern" platform where a bazar of plugin is available. WordPress has only a UI, JIRA, OJS, eprints (sight :-) ) all have only an UI
[21:00] <PeterDietz> UserAgent / DNS would be immensely useful things to filter on too.
[21:00] <PeterDietz> I'm also looking at project honeypot API
[21:00] <tdonohue> PeterDietz: Solr Stats have a command you can run (or schedule via cron) to pull down the latest IP lists. But, yes, ideally, we'd do something like what Ds-790 suggests
[21:01] <mhwood> https://github.com/mwoodiupui/DSpace/tree/DS-790
[21:01] <kompewter> [ mwoodiupui/DSpace at DS-790 · GitHub ] - https://github.com/mwoodiupui/DSpace/tree/DS-790
[21:01] <kompewter> [ https://jira.duraspace.org/browse/DS-790 ] - [#DS-790] SOLR - Spider detection to match on hostname or useragent - DuraSpace JIRA
[21:01] <bollini> helix84: we should share as much as possible, it is only difficult to maintain script/tools etc that are in several languages
[21:02] <PeterDietz> mhwood: Essentially, I'm looking at: https://github.com/mwoodiupui/DSpace/commit/6aaccc5e3bcae4c3887898da2f1a1e0ffe8885c2
[21:02] <kompewter> [ Apply patch extracted from old SVN development tree · 6aaccc5 · mwoodiupui/DSpace · GitHub ] - https://github.com/mwoodiupui/DSpace/commit/6aaccc5e3bcae4c3887898da2f1a1e0ffe8885c2
[21:02] <robint> Got to run, cheers all
[21:03] * robint (522a6b02@gateway/web/freenode/ip.82.42.107.2) Quit (Quit: Page closed)
[21:03] <tdonohue> helix84: as bollini says, please do share your jython scripts. The only problematic part is what the "Committers as a whole" can maintain. But, hopefully we can find other "subsets" of developers who are willing to help maintain scripts in other languages. So, one could imagine a "dspace-jython-tools" modules (or a better name) which could be maintained by 4-5 folks (who may or may not be central Committers)
[21:05] <mhwood> We should have an organized "contrib section" for stuff that's broadly useful but for some reason is thought not to belong "in the box".
[21:05] <helix84> dspace-contrib
[21:06] <tdonohue> I'd love to have a "contrib" section somewhere. Just haven't been able to figure out how best to set that up / manage it. Open to ideas though
[21:06] <tdonohue> we could just create a "dspace-contrib" GitHub, if it's that simple. But, then someone would need to manage it & dole out permissions or what have you.
[21:06] <helix84> it could be a repo, but if we want to give write access to a wider group than just commiters, it would have to live under a different GitHub organization than DSpace, because the contrib commiters need to be members of the owning GitHub organization
[21:07] <PeterDietz> I'm confused by "contrib", We're talking about the bazaar of plugins/features/themes/UI's right?
[21:07] <helix84> so, something like http://github.org/DSpace-contrib/DSpace-contrib would work
[21:08] <mhwood> "contrib" stuff can be developed anywhere. It's not part of boxed-DSpace development (no matter who develops it). But there should be a place to *publish* the results of development, where people can look for cool stuff.
[21:08] <helix84> PeterDietz: yes
[21:08] <PeterDietz> ok, I vote to keep the bazaar out of the cathedral. Build a "codex", a webapp / registry for people to publish their wares
[21:08] <helix84> a wiki page doesn't work very well, as you can see here: https://wiki.duraspace.org/display/DSPACE/Repository+of+XMLUI+themes
[21:08] <kompewter> [ Repository of XMLUI themes - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Repository+of+XMLUI+themes
[21:09] <helix84> we need something that can be easily pulled as a whole, but with lower barriers to entry
[21:09] <helix84> that's why we're talking about a complementary repo
[21:10] <tdonohue> we don't have staffing/developers to build or maintain a "codex", as nice as that'd be. We need something simple & relatively low barrier to entry
[21:10] <mhwood> Or a volunteer.
[21:11] <tdonohue> So, anything we did would have to be simple... relatively easy to maintain (otherwise it could get outdated quickly), and relatively low barrier to entry
[21:11] <mhwood> Aaaand, I have to go. Will check the log later.
[21:11] <helix84> what do you mean by codex? I know Wordpress codex, which is a developer's documentation, but it seem that's not what you mean.
[21:11] <hpottinger> I think a lower-barrier repository, community-driven, would probably work fine
[21:11] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[21:11] <tdonohue> GitHub does seem like a decent candidate...but then we'd need to just determine who is the "gatekeeper" to let things in
[21:11] <hpottinger> there are Wordpress plugins for tracking github repositories
[21:12] <tdonohue> helix84: PeterDietz was the one who called it a "codex" = "a webapp / registry for people to publish their wares"
[21:12] <helix84> how's that different from a free-to-register wiki?
[21:13] <PeterDietz> I said codex, in terms of a code-exchange. You can advertise your plugins, modules, plugins, UIs. WordpressCodex is more of a wiki. They have some other thing that lists whats available 3rd party
[21:14] <helix84> so, like mozilla addons?
[21:14] <hpottinger> surely there communities have solved this same problem?
[21:14] <hpottinger> s/there/there are/g
[21:14] <kompewter> hpottinger meant to say: surely there are communities have solved this same problem?
[21:15] <tdonohue> There's the idea of the addon "marketplace", e.g. Atlassian https://marketplace.atlassian.com/ But, I have no idea what they are using to power it
[21:15] <kompewter> [ Browse, Try, and Buy Add-ons for Atlassian Software | Atlassian Marketplace ] - https://marketplace.atlassian.com/
[21:16] <tdonohue> various other sites have similar "marketplaces" where you can download (or buy) addons to [insert software name]. Not sure that there's an easy way to do set that up though (would love to find out if it's out there)
[21:17] <PeterDietz> yep. I'd say goals are to connect 3rd party features to someone looking to extend their platform. Offer some type of information / documentation / support / Download-and-install-plugin functionality. So yes, an AppStore / Play Store for DSpace.
[21:18] <tdonohue> The keys here are: DuraSpace doesn't have the staff (or funding) do build or maintain something like this ourselves. So, we'd really need to either outsource or buy something (or find an open source product to install). IF nothing is easily available, we'd have to go with something that can just "get the job done" (e.g. GitHub)
[21:19] <helix84> app store _sounds_ like it would offer only addons that don't require you to rebuild dspace. there are plenty of existing addons that require you to build dspace with them. just trying to clarify what we are addressing here.
[21:20] <tdonohue> helix84: ideally, it's an "appstore". But, short term, you are right. Currently DSpace doesn't deal so well with all types of "addons".
[21:21] <hpottinger> I'm thinking we'd be holding both source code (themes, etc.) and artifacts (curation scripts, maybe other things?)
[21:21] <helix84> the difference between wordpress (which offers plugins) and dspace is that you don't need to recompile wordpress
[21:21] <tdonohue> So, while the long term "dream" might be a DSpace AppStore. The short-term reality is that DSpace may need something in the interim...it's not like Wordpress in terms of plugins
[21:22] <helix84> hpottinger: themes, aspects, curation scripts and addons that can be deployed as a separate webapp are not a problem. what about things that depend on changes to core dspace (i.e. rebuilding dspace)
[21:22] <hpottinger> so, would GitLab be a start? (http://gitlab.org/)
[21:22] <helix84> AFAIK, gitlab is just a local GitHub
[21:23] <helix84> would it give us anything that GitHub doesn't?
[21:23] <hpottinger> GitHub doesn't like to store built things
[21:24] <tdonohue> Does GitLab handle "built things" differently somehow then?
[21:24] <helix84> i have a hard time finding gitlab documentation
[21:25] <hpottinger> GitHub can and does store built objects (I'm looking at *you* Isalndora) but I don't think the GitHub folk like it
[21:25] <PeterDietz> You can upload a file to your "downloads" in github. I wouldn't recommend an alternative DVCS system. By all means, 3rd PArty DSpace developers should have a github repo for their feature. The "app store" will be where 3rd party developer registers their repository, and links to their documentation / etc
[21:25] <helix84> closest what I found to docs: https://github.com/gitlabhq/gitlabhq/blob/master/README.md
[21:25] <kompewter> [ gitlabhq/README.md at master · gitlabhq/gitlabhq · GitHub ] - https://github.com/gitlabhq/gitlabhq/blob/master/README.md
[21:26] <helix84> I don't see anythong beyond GitHub-like features there
[21:27] <bollini> sorry, today I was not so present as I would like... I need to go I will check the irc log later
[21:27] <PeterDietz> oops, github deprecated/killed the file uploads: https://github.com/blog/1302-goodbye-uploads
[21:27] <kompewter> [ Goodbye, Uploads · GitHub ] - https://github.com/blog/1302-goodbye-uploads
[21:27] * bollini (~chatzilla@host139-236-dynamic.42-79-r.retail.telecomitalia.it) Quit (Quit: ChatZilla 0.9.90 [Firefox 21.0/20130511120803])
[21:27] <tdonohue> right, hpottinger. Git in general doesn't much like binary stuff (as it cannot 'diff' it as well as text/code -- and binary files therefore use more storage). I'd suspect GitLab would be similar to GitHub.
[21:28] <hpottinger> I was mostly thinking in terms of "if GitHub won't do what we need, maybe something like GitHub, that we can hack/extend will work"
[21:28] <helix84> tim: gitolite laughs at you :)
[21:30] <tdonohue> What if DSpace actually defined a "Plugin" structure as being essentially a "zipped up" Maven project. You could potentially point DSpace at a GitHub tag, have it unzip & build/install via Maven. (Crazy idea, I know)
[21:30] <helix84> s/gitolite/bup/
[21:30] <kompewter> helix84 meant to say: tim: bup laughs at you :)
[21:30] <helix84> sorry :)
[21:31] <tdonohue> bup?
[21:31] <PeterDietz> I have to head out all. Hopefully we can steer this towards something tangible that will help build up the ecosystem
[21:31] <helix84> backup solution that uses the the git repo format
[21:32] * l_a_p (~chatzilla@93.49.188.236) Quit (Quit: ChatZilla 0.9.90 [Firefox 16.0.2/20121024073032])
[21:32] <tdonohue> found it : https://github.com/bup/bup
[21:32] <kompewter> [ bup/bup · GitHub ] - https://github.com/bup/bup
[21:34] <tdonohue> So, to bring this back around. I think we all agree that we need something similar to this concept of a "codeshare" or "marketplace" for DSpace. The key here is to find something we can reasonably support/maintain. We could build a Ferrari but it'd take 5 years (and lots of money or dev time), or we can work towards something that meets the general needs now and build/learn from that.
[21:35] <tdonohue> I obviously lean towards the latter. We need to be "lean" as we don't have the $$ that Atlassian (and similar have). GitHub seems like a great candidate for now. But, I'm definitely open to other ideas/options if someone comes across something else that'd be nice to try
[21:37] <tdonohue> I personally wish there was some sort of open source software out there that'd help us to set this sort of thing up :) But, I'm not finding anything yet
[21:38] <helix84> we might be approaching this from the wrong direction - we're looking for a tool, but we haven't said whether we want to put nails in or cut a branch
[21:41] <helix84> the one goal I think we'll all agree on is to have a central place to hold or link to all dspace addons/themes/aspects/servlets/scripts/modifications/webapps/tools
[21:42] <helix84> the two problems I see are 1) hold or link 2) that's a pretty diverse bunch - we may need to treat each category differently
[21:44] <tdonohue> Ideally, in my mind...we'd *link* to where these things are available. But, if that's too difficult, we could "hold" releases (though we would not maintain them). I agree though the categories of what could be built is rather broad
[21:48] <tdonohue> Essentially we're just trying to help people: (1) Share their useful "stuff" & find other useful "stuff" for DSpace, (2) Know where to go for maintenance/updates or questions (these things would not be maintained by the Committer Team, obviously)
[21:49] <tdonohue> (Longer term -- it might be nice to find a way to support a full "marketplace", similar to Atlassian or WordPress. But, first we'd have to come up with a way to easily install "plugins" in DSpace without requiring a restart)
[21:51] <tdonohue> Well, I have to go here shortly as well. Been a nice discussion. Just need to better determine where to start with this... I feel like we have several different visions here still
[22:00] * Gggggg (522a6b02@gateway/web/freenode/ip.82.42.107.2) has joined #duraspace
[22:04] * Gggggg (522a6b02@gateway/web/freenode/ip.82.42.107.2) Quit (Ping timeout: 250 seconds)
[22:16] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) has left #duraspace
[22:18] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has left #duraspace
[22:23] * helix84 (~a@ip4-95-82-147-170.cust.nbox.cz) Quit (Quit: helix84)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.