Timestamps are in GMT/BST.
[2:06] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Quit: bradmc)
[2:09] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[3:16] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Quit: bradmc)
[6:38] -hitchcock.freenode.net- *** Looking up your hostname...
[6:38] -hitchcock.freenode.net- *** Checking Ident
[6:38] -hitchcock.freenode.net- *** Found your hostname
[6:38] -hitchcock.freenode.net- *** No Ident response
[6:38] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:38] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:38] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[12:14] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[12:53] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[14:10] * tdonohue (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) has joined #duraspace
[19:02] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has joined #duraspace
[19:33] * KevinVdV (~KevinVdV@d54C154B1.access.telenet.be) has joined #duraspace
[19:46] <tdonohue> Hi all, reminder we our back to the normal weekly DSpace Developer Mtg schedule. Meeting today in about 15 mins: https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-03-07
[19:46] <kompewter> [ DevMtg 2012-03-07 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-03-07
[20:01] <tdonohue> Hi all, welcome. Time to begin our weekly DSpace Developers Mtg : https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-03-07
[20:01] <kompewter> [ DevMtg 2012-03-07 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-03-07
[20:01] <tdonohue> we'll kick things off with our usual JIRA review: https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+resolution+%3D+Unresolved+AND+Key%3E%3DDS-956+ORDER+BY+key+ASC
[20:01] <kompewter> [ https://jira.duraspace.org/browse/DS-956 ] - [#DS-956] Skip from Item page to next Item in Browse results without having to return to Browse results page - DuraSpace JIRA
[20:01] <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-956+ORDER+BY+key+ASC
[20:01] <tdonohue> starting with DS-956
[20:01] <kompewter> [ https://jira.duraspace.org/browse/DS-956 ] - [#DS-956] Skip from Item page to next Item in Browse results without having to return to Browse results page - DuraSpace JIRA
[20:02] <mhwood> Sounds like a nice feature, but we would have to save a lot of state somewhere.
[20:02] <tdonohue> yeah, would definitely require saving some state info
[20:03] * mdiggory (~mdiggory@rrcs-74-87-47-114.west.biz.rr.com) has joined #duraspace
[20:04] <tdonohue> anyone in this chat interesting in looking into ways we could implement Ds-956 (maybe your institution is interested in this?). Just thought I'd ask. I agree, it sounds like a nice feature
[20:05] <tdonohue> I think Ivan has a nice idea for embedding some state info into XMLUI (though you probably need more than just a next/previous reference)
[20:05] * aschweer (~schweer@schweer.its.waikato.ac.nz) has joined #duraspace
[20:06] <mhwood> So, thinking back to last week's discussion, how do we factor that out, since JSPUI sites will want it too.
[20:06] <mdiggory> We've actually been doing something like this in Discovery Instead
[20:06] <mhwood> (And Freemarker sites....)
[20:07] <tdonohue> mdiggory -- so, Discovery can/will do this eventually?
[20:07] <mdiggory> In that case, we retain the Discvoery Search Results and the Position in the Results, then add navigation links at the top of the page.
[20:08] <tdonohue> is this something that is planned for a future Discovery release then? Just wondering if we should add comments here that Discovery plans to implement this issue in a future release.
[20:09] <mdiggory> I"m not sure it will be in the contribution at this point
[20:11] <mdiggory> It was actually very light wieght, an XMLUI aspect and some theming changes
[20:11] <mhwood> Anyway, is there some way to make this a service of the browse provider, that the UIs just call on?
[20:11] * PeterDietzHome (~Angie@d60-65-161-223.col.wideopenwest.com) has joined #duraspace
[20:11] <tdonohue> mhwood -- I think that'd be the idea if it was in Discovery. Then any UI which is made Discovery-compatible could use it
[20:11] <mdiggory> Its actually more like "View Search Results One at a Time" than it is retain navigation on the Item View itself
[20:13] <tdonohue> ok. well, we might as well move on for now. Not sure that we will get anywhere more with this? Basically we need a volunteer for Ds-956
[20:13] <mdiggory> mhwood: there are some ideas in that direction, yes
[20:13] <tdonohue> Ds-956 Summary: Good idea, needs a volunteer. Perhaps implement in Discovery as an option?
[20:13] <PeterDietzHome> hmm, I was thinking of a previous and next direction to go from an item
[20:14] <PeterDietzHome> i.e. viewItem @ handle/12345/3344.. you could click a link to go to handle/12345/3344/next which then has the controller go to next item
[20:14] <mdiggory> I would say that if we want to continue on the topic of Discovery being default in 3.0, this would ease implementation of these sort of features to again, only need to focus on one implementation to be able to accomplish them.
[20:14] <PeterDietzHome> like mhwood said, to allow the state from a search to have an item's next, would require a bit more state
[20:15] <mhwood> But the Item doesn't know what's in your browse result.
[20:15] <mdiggory> PeterDietzHome: that is the general approach, yes
[20:15] <tdonohue> +1 mdiggory. That's my thoughts too. If we manage to get behind Discovery, then that simplifies the number of solutions we need
[20:15] <mdiggory> mhwood: that is why I said "mdiggory: Its actually more like "View Search Results One at a Time" than it is retain navigation on the Item View itself"
[20:16] <tdonohue> PeterDietzHome: like mhwood said -- 'handle/12345/3344/next' wouldn't have any meaning without knowing whether you are browsing, searching, etc.
[20:17] <PeterDietzHome> then you would have more state search/rocket+NASA/item/34556 that can have a next
[20:17] <mdiggory> Here is an example of our URL retaining the state.
[20:17] <mdiggory> http://host/handle/10211.6/179?order=DESC&rpp=10&sort_by=score&page=1&group_by=none&etal=0
[20:18] <tdonohue> ok, should we move along for now?
[20:18] <mdiggory> the next Item is
[20:18] <mdiggory> http://host/handle/10211.6/161?order=DESC&rpp=10&sort_by=score&page=1&group_by=none&etal=0
[20:19] <mdiggory> so, it just exposes discovery query detains in the Item Page
[20:19] <mdiggory> detains = details
[20:19] <PeterDietzHome> i guess we can proceed
[20:19] <tdonohue> makes sense - I suggest we move along for now & put the above discussion in comments of Ds-956, so that hopefully we can find a volunteer for it
[20:20] <tdonohue> as we're already 20mins into a full schedule, I'm going to stop JIRA review there for now
[20:20] <mdiggory> I'll pass on the recommendation to our team, do continue
[20:20] <tdonohue> Next up...Reminder that OR12 DSUG proposals are due by end of day tomorrow (Robin Rice asked me to remind everyone)
[20:21] <tdonohue> It sounds like they are still hoping for some more proposals to be submitted -- so if you have anything unique/novel you are doing with DSpace, I'd suggest submitting a talk (if you can attend)
[20:21] <mdiggory> thanks, yes we are in full proposal writing mode ;-)
[20:22] <tdonohue> good deal, just wanted to remind everyone :)
[20:22] <tdonohue> ok. next up, our DSpace GSoC Ideas Page is currently empty! https://wiki.duraspace.org/display/GSOC/DSpace+Summer+of+Code+Ideas
[20:22] <kompewter> [ DSpace Summer of Code Ideas - Google Summer of Code - DuraSpace Wiki ] - https://wiki.duraspace.org/display/GSOC/DSpace+Summer+of+Code+Ideas
[20:22] <PeterDietzHome> Do you get funding if you have an accepted proposal?
[20:22] <tdonohue> It'd be nice to get a few ideas up there if possible (before Friday, when our GSoC Mentoring Application is due)
[20:23] <tdonohue> PeterDietzHome: not sure. you could always submit and then try to get funding if accepted? Or you could email Robin Rice
[20:23] <tdonohue> So, I was wondering if we wanted to brainstorm any possible GSoC Ideas?
[20:24] <mdiggory> I think most of 2011 could be moved up to 2012
[20:24] <PeterDietzHome> My co-worker just started working on a Ruby on Rails app that talks to fedora objects.. I'm glad he is, because I _still_ don't understand what fedora is.
[20:25] <mhwood> It's a repository backend.
[20:25] <PeterDietzHome> he's gutting all the SOLR from the active-fedora ruby gem, since its very superfluous
[20:25] <PeterDietzHome> a backend yes, holds objects yes, services on objects yes, but what does it do...
[20:26] <tdonohue> mdiggory -- good idea.
[20:26] <mhwood> Whatever the frontend you write for it can manage.
[20:26] <tdonohue> what about a GSoC project to change REST API to use Spring WebMVC (instead of Sakai stuff)? Would that be enough to fill a summer?
[20:26] <PeterDietzHome> Is there any "turn key" fedora?
[20:27] * PeterDietzHome sorry for fedora side-track
[20:27] <mhwood> See e.g. Islandora.
[20:27] <tdonohue> PeterDietzHome: Hydra provides various Ruby on Rails interfaces for Fedora
[20:27] <aschweer> GSoC: in the past, have students gone only for "ooh look shiny new feature" style projects, or have infrastructure-style projects also been attractive?
[20:27] <tdonohue> Hydra: http://hydraproject.org
[20:27] <kompewter> [ projecthydra.org ] - http://hydraproject.org
[20:28] <tdonohue> "shiny" is sometimes more popular -- but we've also had infrastructure projects. So, it depends on the students sometimes
[20:28] <aschweer> tdonohue: ok good to know
[20:29] <mdiggory> I"m rather interested in seeing us look at the approach Hydra (Solritas) is using for indexing Fedora Content and Metadata
[20:29] <tdonohue> Though, I think we have learned that *smaller* projects are sometimes better (I.e. don't make the scope too large that it'd be hard/impossible to finish in a summer. Instead, aim smaller, and expand it if the student is a rockstar and finishes early)
[20:29] <mdiggory> They really focused on capturing relationships between the Fedora Objects in a manner that can be traversed in the search results.
[20:29] <mhwood> REST API shouldn't be too *large*.
[20:30] <PeterDietzHome> There's enough work for the webmvc to make a rest api out of that
[20:30] <hpottinger> PeterDietzHome: another front end for Fedora, fun for tinkering, is https://github.com/emory-libraries/eulfedora
[20:30] <kompewter> [ emory-libraries/eulfedora · GitHub ] - https://github.com/emory-libraries/eulfedora
[20:30] <PeterDietzHome> I would propose, an infrastructure boost that we can do that would make it easier for mentor to keep an eye on their student.. i.e. have a public build/workspace
[20:31] <PeterDietzHome> the student pushes code (to github) and our continuous integration will rebuild some demo.dspace.org/project-X
[20:31] <mdiggory> Sorry Solarizer not Solritas
[20:32] <PeterDietzHome> I felt like it was a lot of work to rebuild the environment on my local computer to verify changes. Plus, it helps to get eyes on something
[20:32] <mhwood> I started on a super-simple Fedora frontend to be done in Spring, but don't have any idea what year there might be something usable. It's mainly for me to learn more about Spring and Fedora.
[20:32] <hpottinger> I agree with mdiggory, most of 2011 can be moved to 2012
[20:33] <PeterDietzHome> so.. if webmvc-rest-student is building a new rest api on webmvc, then rest-clientUI student, can run their project against the webmvc-rest workspace too
[20:33] <tdonohue> ok. So, it sounds like we have: move the 2011 projects forward. Add a project to rework REST API to use Spring WebMVC (as discussed in Summit last week). Others?
[20:34] <PeterDietzHome> mhwood, I read your statement as you'll finish it in the spring (season), but you don't know which year's sping season to stop working
[20:34] <mhwood> I like it. Building against someone else's unfinished work is the sort of stuff we didn't get in school but see in the Real World.
[20:35] <mhwood> Hehe, I stop working when it starts working?
[20:36] <hpottinger> better environment for developing an API, that's for sure, you want plenty of feedback
[20:36] <tdonohue> That sounds like a "good enough" starter list for GSoC. If others come up with more project ideas, honestly feel free to add them in. The more ideas the better (even if they may not be fully fleshed out yet, we can always work on that in coming weeks)
[20:37] <PeterDietzHome> for another project, I could use a minion ( mdiggory's words ) to help bang out elastic-search for dspace-stats, but I'm not sure if that is a full summer's worth of work..
[20:37] <PeterDietzHome> I have elastic-search-usage-event-listener listening and recording UsageEvents, and on a statistics page for now, I have it returning a Page of hits for city=columbus
[20:38] <tdonohue> PeterDietzHome -- feel free to put it up there. Again, I tend to prefer smaller projects (as it really sometimes takes a bit of time for students to learn about DSpace and get going).
[20:38] <PeterDietzHome> the real work, actually, might be in refactoring statistics to not be dependent on solr.. i.e. get an interface in there
[20:38] <tdonohue> yep. makes sense
[20:39] <mhwood> Sounds like we have an opportunity to learn what takes time and effort to come up to speed on DSpace. Maybe we can improve the developer documentation.
[20:39] <tdonohue> ok. in essence of time, gonna move on. definitely post your ideas up to https://wiki.duraspace.org/display/GSOC/DSpace+Summer+of+Code+Ideas
[20:39] <kompewter> [ DSpace Summer of Code Ideas - Google Summer of Code - DuraSpace Wiki ] - https://wiki.duraspace.org/display/GSOC/DSpace+Summer+of+Code+Ideas
[20:39] <PeterDietzHome> Another idea I have, is to have the end-user (i.e. librarian) be able to choose which theme gets applied to her collection
[20:39] <tdonohue> mhwood -- although docs can be a (small) part of a GSoC Project, the majority of the project *must include code* (that's a rule from Google)
[20:40] <PeterDietzHome> i.e. collection of photo's of astronaut orbiting the earth, should get "gallery" theme. User goes to Edit Collection, clicks "gallery" radio button, hits save. Refreshes collection browse list
[20:40] <mhwood> I was thinking more along the line that we can observe someone getting his arms around DSpace development, not that documentation would be a GSoC project.
[20:41] <tdonohue> PeterDietzHome -- post it up on the list. again, sounds like it could make a nice project.
[20:41] <tdonohue> ok. moving on for now (sorry -- just a lot on our plate today. Please continue to brainstorm ideas up on our "Ideas Page")
[20:41] <hpottinger> mhwood: I can tell you that the learning curve has been made much easier by people blogging about their own progress, so, perhaps we could ask the GsoC students to work in a way that is more public, blog their experience?
[20:42] <PeterDietzHome> ...and yet another idea, is to have a theme installer... I.e. OSU produces a MapView theme, publishes it to github/osulibraries/xmlui-map-view.. end user repository types [dspace]/bin/dspace install-theme github/osulibraries/xmlui-map-view
[20:42] <tdonohue> Just mentioning, it's "Official", by a landslide -- we are moving to GitHub. I'll be posting that to the lists later today/early tomorrow.
[20:42] <mhwood> Good thought.
[20:42] <mdiggory> Github wiki?
[20:43] <PeterDietzHome> actually, can I propose we move to mercurial?
[20:43] <PeterDietzHome> jk ;)
[20:43] <mdiggory> AAHHHHH
[20:43] <mhwood> Hey, that was my proposal!
[20:43] <tdonohue> Last year we encouraged students to "blog" (or document) their work up on the main Wiki
[20:43] <tdonohue> (some did it better than others though)
[20:43] <mdiggory> how do I kick people from IRC
[20:43] <PeterDietzHome> .rmpoint PeterDietz
[20:43] <kompewter> PeterDietzHome: I'm sorry, but I'm afraid I can't do that!
[20:43] <tdonohue> So, for the GitHub stuff, we need to start planning out the steps involved in the move.
[20:44] <mdiggory> isnt there some sort of "Blog" addon/theme for confluence?
[20:44] <mdiggory> https://github.com/mdiggory/DSpace/tree/maven-project-consolidation
[20:44] <kompewter> [ mdiggory/DSpace at maven-project-consolidation · GitHub ] - https://github.com/mdiggory/DSpace/tree/maven-project-consolidation
[20:44] <mdiggory> I"m getting more comfortable there
[20:45] <PeterDietzHome> main code is already there, on github, remaining module's need to have someone say, I do actually care about dspace-xmlui-api-lang, and I'll migrate it.. or.. share the steps on how to migrate from svn
[20:45] <mdiggory> Actually, I'd say at this point I've almost completely climbed the learning curve
[20:46] <PeterDietzHome> the bit of reconfiguring, that kshepherd will run into on 3.x release time is how maven needs to be updated to "do git"
[20:46] <mdiggory> the above is the consolidation example, not officially tested
[20:46] <tdonohue> PeterDietzHome: umm..yea, there are several things like dspace-xmlui-api-lang that *must* be moved (as they are used by hundreds of DSpace institutions worldwide)
[20:46] <mdiggory> I did a relase of SWORD common version 1.1 into central via sonotype using git as the source repo
[20:47] <tdonohue> I'd suggest we may want to start up a Wiki page for "GitHub Migration Steps" and then start listing things there that need to be done (and tackling them as a team)
[20:47] <mdiggory> tdonohue: PeterDietzHome yes, those are good first candidates
[20:47] <aschweer> sorry folks, need to run off to another meeting
[20:47] * aschweer (~schweer@schweer.its.waikato.ac.nz) Quit (Quit: leaving)
[20:47] <mdiggory> and will set the stage for the rest
[20:47] <mdiggory> tdonohue: +1
[20:48] <mhwood> tdonohue++
[20:48] <PeterDietzHome> I like how an end-user can edit a file, which automatically creates them a fork, and sends us a pull request with that changes, potentially mega-simplifying the languages https://github.com/DSpace/DSpace/edit/master/dspace-api/src/main/resources/Messages.properties
[20:49] <mdiggory> Github pom changes are pretty minimal, mostly VCS related https://github.com/mdiggory/SWORDv1.1/blob/master/pom.xml
[20:49] <kompewter> [ SWORDv1.1/pom.xml at master · mdiggory/SWORDv1.1 · GitHub ] - https://github.com/mdiggory/SWORDv1.1/blob/master/pom.xml
[20:49] <PeterDietzHome> (looks like you need to be logged in to do that edit Messages)
[20:49] <tdonohue> Ok. I'll take up the task of creating a "GitHub Migration Steps" wiki page, which I'll send along to dspace-commit so that all of you can help me fill it out, etc.
[20:50] <mdiggory> PeterDietzHome: Golden!
[20:50] <mdiggory> I seriously like that feature...
[20:50] <tdonohue> PeterDietzHome: really? it would be nice to simplify language changes. We might want to look into how that process could be eased by GitHub, and talk to Claudia more about it (as she tends to manage it currently)
[20:51] <PeterDietzHome> yep, if you didn't just see if, go to https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/resources/Messages.properties then click "Edit this file"
[20:51] <kompewter> [ DSpace/dspace-api/src/main/resources/Messages.properties at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/resources/Messages.properties
[20:52] <tdonohue> Yea, I see that. I don't imagine this works for 'messages.xml' though?
[20:52] <PeterDietzHome> hint with github.. hit t... the letter t on your keyboard, then type the name of the file your looking for, in this case messages
[20:52] <PeterDietzHome> then hit enter
[20:53] <mdiggory> Hey.... per repo permissions in an organization, very cool too https://github.com/organizations/DSpace/teams
[20:53] <kompewter> [ Log in · GitHub ] - https://github.com/organizations/DSpace/teams
[20:53] * mhwood imagines an XSL transform to produce Messages.properties from messages.xml
[20:53] <tdonohue> oh, cool. it does work for messages.xml too: https://github.com/DSpace/DSpace/edit/master/dspace-xmlui/dspace-xmlui-webapp/src/main/webapp/i18n/messages.xml
[20:53] <mdiggory> so we could have language packs and give rights to different team members than to DSpace itself...
[20:53] <tdonohue> mhwood -- I'd really like that. I *hate* the way we do language packs right now (and from my understanding it frustrates a lot of people)
[20:54] <PeterDietzHome> it works for all files. even java.. someone could pass through and fix typos in our comments, without having to run away because of complexity of "now how do i send this in"
[20:55] <tdonohue> If there was a way to get Cocoon/XMLUI to use 'messages.properties' (doubtful), then I'd love to just ditch 'messages.xml' altogether. But, barring that, transforming messages.properties to messages.xml would be nice (if we could do it)
[20:55] <mdiggory> yes, I like, this is definitely lowering the bar
[20:56] <mdiggory> tdonohue: mhwood I'd rather see a database approach for messages emerge.
[20:56] <mhwood> So then we need to write a DatabaseBundle class and a DatabaseWhateveritisforcocoon class.
[20:56] <mdiggory> right
[20:56] <tdonohue> it's much better in github. But, we still do have a translation issue with the fact that there are so many different "messages" files that folks need to change these days.
[20:57] <mdiggory> and then either a means to import properties files intot he db during install/upgrade
[20:57] <PeterDietzHome> name
[20:57] <PeterDietzHome> dspace-xmlui/dspace-xmlui-webapp/src/main/webapp/i18n/messages.xml
[20:57] <PeterDietzHome> dspace-discovery/dspace-discovery-xmlui-api/src/main/resources/aspects/Discovery/i18n/messages.xml
[20:57] <PeterDietzHome> dspace-sword-client/dspace-sword-client-xmlui-api/src/main/resources/aspects/SwordClient/i18n/messages.xml
[20:57] <PeterDietzHome> dspace-api/src/main/resources/Messages.properties
[20:57] <PeterDietzHome> dspace-xmlui/dspace-xmlui-api/src/main/resources/aspects/XMLWorkflow/i18n/messages.xml
[20:57] <tdonohue> mdiggory -- I'd be open to that idea. Just as long as we can load that DB initially from a *single* file (messages.properties)
[20:58] <tdonohue> PeterDietzHome just proved my point. If you want to fully translate DSpace to Spanish (or any other language) you need to edit 5 files -- and that number is increasing over time (as new ones were created for Discovery, SWORD, XMLWorkflow, etc)
[20:59] <mdiggory> In xmlui, it could be prioritized/overriden such that first properties, then xml, then db giving the ability to designate priorities to override default messages and store the resulting customizations in the db
[20:59] <mhwood> I doubt I'll ever be good in all of the supported languages, so I hope we can attract some *maintainers* for specific translations.
[21:00] <mdiggory> I do think that default messages should be maintained in the module in question, but that the databse would be a point of override for the local institution.
[21:00] <tdonohue> mhwood -- we do have "maintainers" that tend to work with Claudia. But, over time it has become more and more frustrating for those maintainers as we have moved from 1 translation file (messages.properties) to now 5.
[21:01] <tdonohue> mdiggory -- that's OK, as long as people know what properties they need to be overriding elsewhere. Right now, a "maintainer" has to dig around into 5 files and translate each one by one. There's no easier way.
[21:02] * tdonohue realizes we are way off topic, but this is an important point that does need discussing.
[21:03] <mdiggory> with the maven consolidation, its possible that some of these could also go away
[21:03] <tdonohue> It's also worth mentioning that complaints about translating DSpace have now made their way up to DCAT as well. I sat in on today's DCAT meeting and Bram (from @mire) brought this up as an issue and is trying to find ways to help out the translators
[21:03] <mdiggory> PeterDietzHome: dspace-xmlui/dspace-xmlui-webapp/src/main/webapp/i18n/messages.xml
[21:03] <mdiggory> [8:57pm] PeterDietzHome: dspace-discovery/dspace-discovery-xmlui-api/src/main/resources/aspects/Discovery/i18n/messages.xml
[21:03] <mdiggory> [8:57pm] PeterDietzHome: dspace-sword-client/dspace-sword-client-xmlui-api/src/main/resources/aspects/SwordClient/i18n/messages.xml
[21:03] <mdiggory> dspace-xmlui/dspace-xmlui-api/src/main/resources/aspects/XMLWorkflow/i18n/messages.xml
[21:03] <mhwood> DBMS would make it easy to detect missing translations....
[21:03] <mdiggory> these could be merged
[21:03] <mhwood> mdiggory: yeah, but addons could have their own catalogs.
[21:04] <mdiggory> yes they always would...
[21:04] <mdiggory> their addons...
[21:05] <mdiggory> but if we consolidate stats, discovery, xmlui in the manner i've proposed in the consolidation then these files can be consolidated as well
[21:05] <mdiggory> because we are making them default addons in xmlui maintained in dspace-xmlui/src/main/java|resources
[21:06] <mdiggory> https://github.com/mdiggory/DSpace/tree/maven-project-consolidation/dspace-xmlui/src/main/java/org/dspace/app/xmlui/aspect
[21:06] <kompewter> [ DSpace/dspace-xmlui/src/main/java/org/dspace/app/xmlui/aspect at maven-project-consolidation · mdiggory/DSpace · GitHub ] - https://github.com/mdiggory/DSpace/tree/maven-project-consolidation/dspace-xmlui/src/main/java/org/dspace/app/xmlui/aspect
[21:07] <mdiggory> https://github.com/mdiggory/DSpace/tree/maven-project-consolidation/dspace-xmlui/src/main/resources/aspects
[21:07] <kompewter> [ DSpace/dspace-xmlui/src/main/resources/aspects at maven-project-consolidation · mdiggory/DSpace · GitHub ] - https://github.com/mdiggory/DSpace/tree/maven-project-consolidation/dspace-xmlui/src/main/resources/aspects
[21:07] <PeterDietzHome> I like the reconsolidation.. less intermediate directories
[21:07] * PeterDietzHome has to head out soon
[21:07] <tdonohue> mdiggory -- yea, it could solve the problem for specific projects. But, still doesn't really resolve the issue of translation management over time.
[21:08] <mdiggory> Note the new dspace-common-api library for business/app code.
[21:08] <mdiggory> https://github.com/mdiggory/DSpace/tree/maven-project-consolidation/dspace-common-api/src/main/java/org/dspace
[21:08] <kompewter> [ DSpace/dspace-common-api/src/main/java/org/dspace at maven-project-consolidation · mdiggory/DSpace · GitHub ] - https://github.com/mdiggory/DSpace/tree/maven-project-consolidation/dspace-common-api/src/main/java/org/dspace
[21:08] <tdonohue> I think to improve translation management we may need to move more towards DBMS, or we'd have to consolidate on one format (like messages.properties) and find tools that can help us manage translations using that format (like http://translate.sourceforge.net/wiki/pootle/)
[21:08] <kompewter> [ pootle:index · Translate Toolkit & Pootle ] - http://translate.sourceforge.net/wiki/pootle/)
[21:09] * tdonohue says, sorry for going totally off our agenda today :) One last thing to mention before folks head out. We still need a 3.0 "Release Team Leader". Kim won't be able to do it after all as it doesn't fit his upcoming work schedule.
[21:09] * mhwood imagines an XSL transform to turn messages.xml into SQL....
[21:09] <mdiggory> tdonohue: the consolidation helps... and if we were to get to one file format, that would help even more.
[21:10] * tdonohue so if anyone is willing to take on the 3.0 Release Team Leader role, please get in touch. Again, you'll have an entire team helping you out -- so it should be less work than past RCs have had to do.
[21:11] <mdiggory> there was once a report I wrote as part of the maven site build
[21:11] <mdiggory> http://scm.dspace.org/svn/repo/tools/maven/dspace-i18n-report-plugin/trunk/src/main/java/org/dspace/maven/reports/I18nReport.java
[21:11] <mdiggory> I imagint hat a db approach could have "context" associated with it as well
[21:12] * tdonohue if folks need to head out, feel free. We'll consider the official meeting "adjourned", but we can continue this discussion for those who can hang around for a bit.
[21:12] <mdiggory> kind of like what we did with config properties
[21:13] <PeterDietzHome> later all
[21:13] <mdiggory> [module].[property]=value
[21:13] * PeterDietzHome (~Angie@d60-65-161-223.col.wideopenwest.com) Quit (Quit: Leaving)
[21:13] <tdonohue> mdiggory: what exactly does that I18nReport do? It just reports on messages.xml files? Or does it compare translations with the English copy?
[21:13] <mhwood> Actually I wish there were not such a strong link between module and its serialized configuration.
[21:14] <mdiggory> yea, it was supposed to compare them all
[21:14] <mdiggory> mhwood: ?
[21:15] <mhwood> Would like to be able to just drop additional files and have them picked up, like e.g. /etc/xinetd.d/anythingyoulike
[21:16] <mhwood> It's been a while since I thought about it...I'm trying to recall specific problems I had.
[21:16] <mdiggory> in other words, you don't want the properties namespaced?
[21:17] <mhwood> Yes, I think that's it.
[21:17] <mdiggory> I'll admit, thats a bit convoluted
[21:17] * robint (52292725@gateway/web/freenode/ip.82.41.39.37) has joined #duraspace
[21:18] <mdiggory> we tried to avoid it int he ConfigurationService, in fact, theres no concept of namespacing exposed in that API which is different from the ConfigurationManager api changes
[21:19] <mdiggory> Sometimes I think we need to be careful about straying too far from the norm, conventional behavior, some of our team members can be a bit too creative int his regard
[21:19] <mhwood> I remember now. I had to write a Maven plugin to merge stuff into the "main" dspace.cfg because there's no place to just drop additions.
[21:20] <mdiggory> ah, for the test instance
[21:20] <mhwood> Yes.
[21:20] <mdiggory> probibly more to do with the db right?
[21:20] <mhwood> I think so.
[21:22] <mhwood> No, actually it's to do with authority control.
[21:22] <mhwood> #Configure authority control for testing
[21:22] <mhwood> plugin.selfnamed.org.dspace.content.authority.ChoiceAuthority = \
[21:22] <mhwood> org.dspace.content.authority.DCInputAuthority
[21:22] <mhwood> choices.plugin.dc.language.iso = common_iso_languages
[21:22] <mhwood> choices.presentation.dc.language.iso = select
[21:22] <mhwood> authority.controlled.dc.language.iso = true
[21:22] <mdiggory> ok... that conifg is already pretty bad... it needs a serious rewrite...
[21:23] <mdiggory> this is a prime candidate for spring config....
[21:23] <mhwood> Gets stuck on the end of config/dspace.cfg so something can test that.
[21:23] <mdiggory> Any time we see hierarchical config like this... there should be a serious reconsidering.
[21:23] <mhwood> How many different config. mechanisms are we going to have?
[21:24] <mdiggory> if it is new code coming into DSpace. It should be recommended that they switch to Spring config before the work will be accepted
[21:24] <mhwood> Agreed, serialized Properties is terrible for structured data.
[21:24] <mhwood> Do we have a consensus on using Spring for config?
[21:25] <mdiggory> Its already in there
[21:25] <KevinVdV> & allows for a hell of a lot more then any .cfg configuration :)
[21:25] <mhwood> I agree, but do we have a consensus that that's our direction?
[21:25] <mdiggory> http://scm.dspace.org/svn/repo/dspace/trunk/dspace/config/spring/
[21:25] <kompewter> [ repo - Revision 6957: /dspace/trunk/dspace/config/spring ] - http://scm.dspace.org/svn/repo/dspace/trunk/dspace/config/spring/
[21:26] <mdiggory> People vote with their feet
[21:26] * hpottinger is a big proponent of, if it's the right thing to do, do it, let the consensus follow
[21:27] <tdonohue> IIRC we had talked about there being several "levels" of configuration. There's the configuration to "install something" (which likely should move towards Spring, but we haven't had a consensus there yet), and then there's the configuration to actually "setup/configure something once installed" (which may be in DB/.cfg or similar)
[21:29] <mhwood> There's configuration of the installation process itself, which is done by the person doing the installation. There's "configuration" that's baked into the instance, like message catalogs, because it's best externalized from the code. There's configuration of the instance, which is done by the site.
[21:29] <mdiggory> I want to caution that lazy consensus does allow changes into the codebase that later may be realized were not the best choice. It is not a perfect system.
[21:30] <mhwood> Sometimes we get a bimodal "consensus". Services vs. Managers comes to mind. There are distinct "parties".
[21:31] <mdiggory> The challenge is that sometimes consensus is used as the argument/excuse for not fixing such cases.
[21:31] <mdiggory> which is circular argument
[21:32] <mhwood> I'm not saying we shouldn't use Spring to configure. I think we should. But I hope to see convergence to a single best practice at some point.
[21:33] <tdonohue> I was just clarifying that there are definitely 'levels' to configuration. I generally like the idea of moving towards Spring configuration (for configs which only expert users may wish to tweak). But, obviously things more 'user-facing' need to be more easily manageable in the system (like in the DB, etc)
[21:33] <mdiggory> So for example, while I supported adding swordv2 to the codebase, I do not agree with the versioning approach that is used in it. I cannot go back now and say remove the versioning component of swordv2 because theres not consesus on its inclusion.
[21:36] <mhwood> I think what I was getting at, back a ways, is that sometimes you have to *ask* for consensus or it never jells.
[21:36] <mdiggory> tdonohue: yes I agree that was the most recent dialog on properties. But, does that suggest any sort of consensus?
[21:37] <tdonohue> to get a better "consensus" we'd probably need to call a vote of some sort
[21:38] <tdonohue> or discuss on dspace-commit
[21:38] * robint (52292725@gateway/web/freenode/ip.82.41.39.37) Quit (Quit: Page closed)
[21:41] <KevinVdV> Need to run until next time
[21:41] * KevinVdV (~KevinVdV@d54C154B1.access.telenet.be) Quit (Quit: HydraIRC -> http://www.hydrairc.com <- Like it? Visit #hydrairc on EFNet)
[21:42] <mhwood> I suppose one way forward would be to just start picking configurable things, making them Spring-configurable (for example), and ripping the old config. out of dspace.cfg. If no one puts it back, that's progress.
[21:43] <mhwood> Eventually there's nothing left that makes sense to rework.
[21:45] <mhwood> I could look at doing that for authority control. That would solve my problem.
[21:45] <mhwood> Actually most of the work would be on the plugin manager.
[21:47] <mhwood> Hmmm, could be a good approach generally. When something gets in the way, move it to Spring or database as appropriate, until there's nothing left in dspace.cfg but the answer to "Dude, where's my database?"
[21:48] <hpottinger> which is never in dspace.cfg anyway, it's in a profile
[21:49] <mhwood> ??? db.user=, db.password=, db.url=....
[21:49] <hpottinger> sorry, in my implementation, yes, it's either in a maven profile, or in my own maven.properties
[21:50] <mhwood> The servlet container can supply a ready-made connection pool out of JNDI, but commandline app.s have no such luck. (Although I wrote a package to fix that...)
[21:50] <hpottinger> been meaning to look into how to do the database stuff from the context fragment file
[21:53] <mhwood> http://pastebin.com/KWSNaahe
[21:53] <kompewter> [ <Context docBase='/home/mwood/dspaces/trunk-1.7/webapps/xmlui'> <Param - Pastebin.com ] - http://pastebin.com/KWSNaahe
[21:55] <mhwood> Container-specific. That works for Tomcat. I think I've seen how to do it in Jetty but I haven't used Jetty myself.
[21:59] <mhwood> Gotta go. It's gone quiet, anyway. Thanks, all!
[22:01] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[22:06] <tdonohue> i see i just missed mhwood (had to step away for a moment). In general though, I agree with his approach
[22:06] <tdonohue> I think it's perfectly fine for us to start "picking configurable things and making them Spring-configurable" etc.
[22:07] <tdonohue> I don't think that needs to wait for a larger consensus -- it can just start happening. The only thing I think we do need to do is put up a JIRA ticket first saying e.g. "Move authority control config to Spring" -- this gives folks the chance to comment on it and express concerns or support
[22:17] <hpottinger> since this is a logged channel, I'll just shout out a belated thanks for the pastebin link, mhwood, it's much appreciated
[22:20] * mdiggory (~mdiggory@rrcs-74-87-47-114.west.biz.rr.com) Quit (Quit: mdiggory)
[22:47] * mdiggory (~mdiggory@ip72-199-216-7.sd.sd.cox.net) has joined #duraspace
[23:15] * tdonohue (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[23:20] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has left #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.