Timestamps are in GMT/BST.
[2:54] * awoods (~awoods@c-67-165-245-76.hsd1.co.comcast.net) Quit (Ping timeout: 245 seconds)
[6:45] -leguin.freenode.net- *** Looking up your hostname...
[6:45] -leguin.freenode.net- *** Checking Ident
[6:45] -leguin.freenode.net- *** Found your hostname
[6:45] -leguin.freenode.net- *** No Ident response
[6:45] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:45] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:45] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[8:48] * fasseg (~fas@HSI-KBW-078-043-007-220.hsi4.kabel-badenwuerttemberg.de) has joined #duraspace
[11:36] * eddies (~eddies@unaffiliated/eddies) Quit (Quit: Leaving.)
[12:07] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[12:45] * ksclarke (~kevin@pdpc/supporter/active/ksclarke) has joined #duraspace
[12:46] * ksclarke (~kevin@pdpc/supporter/active/ksclarke) Quit (Client Quit)
[12:46] * ksclarke (~kevin@pdpc/supporter/active/ksclarke) has joined #duraspace
[13:16] * awoods_ (~awoods@c-67-165-245-76.hsd1.co.comcast.net) has joined #duraspace
[13:16] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) has joined #duraspace
[13:20] * awoods_ is now known as aawoods
[14:36] * eddies (~eddies@cm107.eta98.maxonline.com.sg) has joined #duraspace
[14:36] * eddies (~eddies@cm107.eta98.maxonline.com.sg) Quit (Changing host)
[14:36] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[14:47] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has joined #duraspace
[15:11] * eddies (~eddies@unaffiliated/eddies) Quit (Read error: Connection reset by peer)
[15:12] * eddies (~eddies@cm107.eta98.maxonline.com.sg) has joined #duraspace
[15:12] * eddies (~eddies@cm107.eta98.maxonline.com.sg) Quit (Changing host)
[15:12] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[15:18] * PeterDietz (~peterdiet@128.146.173.70) has joined #duraspace
[15:47] * awaterma (~awaterma@200.23.34.33) has joined #duraspace
[15:49] * fasseg (~fas@HSI-KBW-078-043-007-220.hsi4.kabel-badenwuerttemberg.de) Quit (Quit: Leaving)
[15:55] <awaterma> Hi! I was wondering if anyone on channel could talk to me a bit about the ingestion process and how crosswalks work during ingestion. I can't seem to find deep documentation around the process.
[16:11] * awaterma (~awaterma@200.23.34.33) has left #duraspace
[16:24] * linux4u (~james@employed.library.emory.edu) has joined #duraspace
[18:36] * bram-atmire (~bram@94-225-35-170.access.telenet.be) has joined #duraspace
[18:38] <bram-atmire> hi
[18:39] * hpottinger waves
[18:40] <bram-atmire> seems like the general meeting page said 20 UTC, but today's meeting page said 19UTC
[18:40] <bram-atmire> change the main page into 19UTC?
[18:40] <bram-atmire> https://wiki.duraspace.org/display/DSPACE/Developer+Meetings
[18:40] <kompewter> [ Developer Meetings - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Developer+Meetings
[18:41] <bram-atmire> ah my mistake
[18:41] <bram-atmire> 19 UTC is the JIRA backlog hour
[18:41] <tdonohue> yep. regular mtg still is 20 UTC
[18:42] <hpottinger> backlog hour in other room
[18:46] <bram-atmire> I arrived home late and decided to make a meatloaf, already 8.45pm and still need to have that thing 45 minutes in the oven before dinner :/
[19:12] * bram-atmire (~bram@94-225-35-170.access.telenet.be) Quit (Quit: bram-atmire)
[19:30] * helix84 (~a@ip4-95-82-147-170.cust.nbox.cz) has joined #duraspace
[20:00] * jonathangee (~jonathang@blk-222-249-31.eastlink.ca) Quit (Ping timeout: 245 seconds)
[20:01] <tdonohue> Hi all, it's that time again. The weekly DSpace Developers Mtg is starting now. Today's general agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-05-08
[20:01] <kompewter> [ DevMtg 2013-05-08 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-05-08
[20:01] <tdonohue> as in recent weeks... we're going to start things off with a few Pull Request reviews
[20:02] <tdonohue> Here's our current PRs (oldest first): https://github.com/DSpace/DSpace/pulls?direction=asc&page=1&sort=created&state=open
[20:02] <kompewter> [ Pull Requests · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pulls?direction=asc&page=1&sort=created&state=open
[20:02] <tdonohue> this week we're starting at #114 : https://github.com/DSpace/DSpace/pull/114
[20:02] <kompewter> [ Adds support for read-only contexts that bypass internal DSO cache by richardrodgers · Pull Request #114 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/114
[20:03] <tdonohue> related to DS-1205
[20:03] <kompewter> [ https://jira.duraspace.org/browse/DS-1205 ] - [#DS-1205] DSpace org.dspace.core.Context caching problem - DuraSpace JIRA
[20:03] * bollini (~chatzilla@host136-17-dynamic.53-79-r.retail.telecomitalia.it) has joined #duraspace
[20:04] <helix84> both richard and joao tested it and approved it, so i'd say we go ahead
[20:04] * l_a_p (~chatzilla@93-63-22-159.ip25.fastwebnet.it) has joined #duraspace
[20:04] <mhwood> Has one independent test.
[20:04] <mhwood> Yes.
[20:05] <tdonohue> looks like hpottinger tested too (in comments of Ds-1205). So, we only "held back" cause it was a central change (to Context object). Seems like it should be merged
[20:06] <tdonohue> merged into "master" that is, for 4.0
[20:07] <tdonohue> want to do the honors, hpottinger, since you were a tester here?
[20:07] <mhwood> Now is a good time, lots of time to test and (if needed) fix.
[20:07] <hpottinger> ooh, I get to push the button?
[20:07] <tdonohue> yep. push the button & close Ds-1205 :)
[20:08] <tdonohue> (and mark it fixed for 4.0 .. not 3.2 as it currently states)
[20:08] <tdonohue> moving along...want to try and get one more PR review in today.
[20:08] <tdonohue> # 116 : https://github.com/DSpace/DSpace/pull/116
[20:08] <kompewter> [ Porting advanced embargo function to JSPUI by zuki · Pull Request #116 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/116
[20:09] <hpottinger> ok, just to be clear, we're talking about merging PR114
[20:09] <helix84> 116 needs at least one person to look at it
[20:09] <tdonohue> hpottinger -- yea...sorry. Ds-1205 relates to PR #114. In the comments in Ds-1205, you'll see we already agreed to PR #114 but delayed it cause it changed Context
[20:10] <hpottinger> just had to ask because 114 refers to 161
[20:10] <helix84> other than that, a minor technicality: there was a merge master->feature beanch done, which doesn't look nice in history, so it could use a rebase
[20:10] <tdonohue> hpottinger -- so, PR #114 can be merged. And Ds-1205 can be closed & marked fixed for 4.0.
[20:11] <hpottinger> helix84: would you like to do the honors with the rebase?
[20:11] <helix84> hpottinger: no problem doing a rebase, but i don't think i can properly test it
[20:11] <mhwood> 116 had two reviews.
[20:12] <helix84> mhwood: neither joao nor me actually ran the code
[20:12] <helix84> bollini: would you be interedted in testing embargo interface for jspui?
[20:13] <bollini> yes, we can test it in the next days
[20:13] <helix84> can i assign it to you, then?
[20:14] <tdonohue> sounds good. So, for #116 helix84 will rebase & bollini will help test.
[20:14] <helix84> i'll create a ticket and prepare a rebased branch
[20:14] <tdonohue> sounds good. Yes, it does need a JIRA ticket
[20:15] <helix84> i found the ticket :)
[20:15] <hpottinger> oh, I see, I was confused, I thought helix84 was suggesting a rebase for PR114
[20:16] <tdonohue> hpottinger: nope, PR # 114 is "clean"...it's a single commit (actually rather small)
[20:16] * hpottinger is gonna push that button right now
[20:16] <tdonohue> it's just PR # 116 that's a bit "messy" and needs a rebase.
[20:16] <bollini> this is a good opportunity to test also my pull request for DS-1466
[20:16] <kompewter> [ https://jira.duraspace.org/browse/DS-1466 ] - [#DS-1466] withdrawn and private items are indexed in Solr search - DuraSpace JIRA
[20:17] <mhwood> #183
[20:17] <tdonohue> https://github.com/DSpace/DSpace/pull/183
[20:17] <kompewter> [ DS-1466 private items must be excluded in default discovery search by abollini · Pull Request #183 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/183
[20:18] <bollini> so, helix84 please rebase #116, I and l_a_p (he is a collegue from CINECA) will test #116 and DS-1466 (I have reassigned the issue to me)
[20:18] <kompewter> [ https://jira.duraspace.org/browse/DS-1466 ] - [#DS-1466] withdrawn and private items are indexed in Solr search - DuraSpace JIRA
[20:18] <helix84> bollini: i'll do so right away
[20:20] <tdonohue> Ok. So, we'll close up PR reviews for today
[20:21] <tdonohue> Next on the agenda...just a few minor announcements. Again, signup to attend the OR13 DSpace Developer Mtg (most of you have) if you plan to attend
[20:22] <tdonohue> Also, just wanted to note that tomorrow & Fri is the "DSpace 3-5 year Vision" meeting in Chicago (I'll be attending on behalf of the Committers). Again, this is that high-level vision/roadmap meeting that we've mentioned here several times
[20:22] <hpottinger> fyi, PR114 merged, Ds1205 closed
[20:22] <tdonohue> I'll send you all an email regarding any outcomes / draft vision statements from that meeting (likely get it to you early next week - Mon or Tues)
[20:23] <tdonohue> If you want any more info -- we have our agenda publicly on the DSpace wiki (and notes from the meeting will be written directly on the wiki as well). Here's that agenda page:
[20:23] <tdonohue> https://wiki.duraspace.org/display/DSPACE/DSpace+2013+Vision+and+Roadmap+Meeting
[20:23] <kompewter> [ DSpace 2013 Vision and Roadmap Meeting - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+2013+Vision+and+Roadmap+Meeting
[20:24] <tdonohue> As mentioned, we had to keep the attendee list small..but we tried to get it as "diverse" as we could on short notice. Any outputs from this meeting will only be a *draft* and will be reviewed by Committers & the DSpace Community in general
[20:26] <tdonohue> I think that's all I had to say... Just trying to be as "transparent" as possible. If there are questions, I'd be glad to answer. Obviously we'll discuss the outcomes of this meeting together (it's also on our OR13 Mtg agenda)
[20:28] <tdonohue> Hearing no questions... I'm going to move along to next topic for now
[20:28] <tdonohue> Next up is DSpace 4.0 Planning & Discussions. As noted on the agenda, we have two Release Team members so far -- hpottinger & mhwood. Thanks to them both (and their bosses/institutions)
[20:29] <tdonohue> We still are looking for more Release Team members though...so, if you are interested, please do get in touch
[20:29] <hpottinger> even mild interest is acceptible
[20:29] <tdonohue> definitely
[20:30] <tdonohue> ideally we'd have somewhere between 3-5 folks on the Release Team. I think for 3.0 we had 4 team members.
[20:31] <tdonohue> with regards to 4.0, it's also time to start talking about Release Timelines (when / how), and obviously continue to plan features (what)
[20:32] <tdonohue> We do have a 4.0 Release notes page up already. It would be good to start capturing on that page what features folks may be working on for 4.0: https://wiki.duraspace.org/display/DSPACE/DSpace+Release+4.0+Notes
[20:32] <kompewter> [ DSpace Release 4.0 Notes - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+Release+4.0+Notes
[20:33] <tdonohue> That way we can get a better feel for what is in the "pipeline" and even potentially how we could start to "schedule" things to be merged (if the RT wants to go that route)
[20:34] <tdonohue> so, currently on that wiki page, all we really have is a "Wish List": https://wiki.duraspace.org/display/DSPACE/DSpace+Release+4.0+Notes#DSpaceRelease4.0Notes-WishListforDSpace4.0%28tentative%29
[20:34] <kompewter> [ DSpace Release 4.0 Notes - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+Release+4.0+Notes#DSpaceRelease4.0Notes-WishListforDSpace4.0%28tentative%29
[20:34] <tdonohue> though I know that "wish list" doesn't include a lot of stuff we've brainstormed recently that may (or may not) be something to work towards with 4.0
[20:35] <tdonohue> things I've heard mentioned with 4.0 include: REST-API (actually getting one in place), reworking AuthN/AuthZ to use third party solution, ....
[20:35] <tdonohue> I know there's more...I'm just blanking now :)
[20:36] <mhwood> Time to talk up your favorites.
[20:36] <hpottinger> AuthZ/N + added bonus of "permissions are weird" general spruce-up
[20:36] <PeterDietz> I can add REST API to the "wish list" for 4.0
[20:36] <tdonohue> yes...definitely, talk up your favorites everyone
[20:36] <tdonohue> thanks PeterDietz -- definitely do so.
[20:37] <tdonohue> & hpottinger, if you want to add AuthN/Z notes to "Wish List" that'd be nice too
[20:37] <tdonohue> Currently the only item on the "Wish List" is getting the old "Metadata For All" objects PR updated for 4.0
[20:37] <tdonohue> (PR #12)
[20:38] <hpottinger> before I add notes, I'll need help getting specific with "permissions are weird" I need ticket numbers
[20:38] <tdonohue> Anything else that folks want to add to our 4.0 list? Something else you may be working on that you hope to have ready for 4.0?
[20:39] <mhwood> Turn ConfigurationManager into a shell around ConfigurationService.
[20:39] <mhwood> See DS-1390
[20:39] <helix84> I think we should be adding not merely things we wish, but things that are being worked on
[20:39] <kompewter> [ https://jira.duraspace.org/browse/DS-1390 ] - [#DS-1390] DSpace has too many configurations - DuraSpace JIRA
[20:40] <tdonohue> hpottinger: Some of the "permissions are weird" tickets include: DS-880, DS-476. There's likely more out there that describe oddities with permissions / authN/AuthZ
[20:40] <helix84> (i'm pointing at AuthZ/N here)
[20:40] <kompewter> [ https://jira.duraspace.org/browse/DS-880 ] - [#DS-880] Better documentation for permissions - DuraSpace JIRA
[20:40] <kompewter> [ https://jira.duraspace.org/browse/DS-476 ] - [#DS-476] READ action - DuraSpace JIRA
[20:41] <tdonohue> helix84 -- yea, agreed. It's not just a "wish list". We do want to make sure someone is volunteering to work on the feature. But, with AuthN/AuthZ, I've heard mhwood & hpottinger both mention at least an *interest* in investigating something for 4.0
[20:41] <tdonohue> mhwood: Would love to see DS-1390 happen
[20:41] <kompewter> [ https://jira.duraspace.org/browse/DS-1390 ] - [#DS-1390] DSpace has too many configurations - DuraSpace JIRA
[20:41] <helix84> ok, sorry, I didn't know about that
[20:42] <helix84> tdonohue: did you look at https://github.com/DSpace/DSpace/pull/61 ?
[20:42] <kompewter> [ Enabling Dynamic DSpace Configuration Manager by lyncodev · Pull Request #61 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/61
[20:43] <tdonohue> we discussed PR #61 in a meeting a few weeks back (see last comment there)
[20:43] <helix84> mdiggory is the only one who really commented on the design
[20:44] <helix84> it's basically in a limbo waiting for comments
[20:45] <tdonohue> looking back 2 weeks (4/24 meeting), at that point it was said that "Lyncode has been working on this idea since then".
[20:45] <tdonohue> So, I think it's "in limbo" cause no one knows what is the "latest". Is PR #61 the latest work? Is there more to know about? what should we comment on?
[20:45] <helix84> yes, wouldn't hurt to check
[20:46] <helix84> but the call for comments is still open
[20:46] <tdonohue> But, in my opinion, I'd love to see something like PR # 61 happen in 4.0. But, we need to know what to review...so we can do so.
[20:47] <helix84> is the general design something most of us agree on? do we prefer file-based or DB-based storage?
[20:47] <helix84> this is a change that touches every single user and developer, so I'm surprised so little of us have expressed an opinion
[20:48] <mhwood> Some configuration has complex structure and is simply horrible to work with. I'm not so sure how that would fit into a DB-backed scheme. (See the plugin configuration, for example.)
[20:49] <tdonohue> I'm perfectly fine with Configs staying in Files. I think I mentioned this last time we talked about PR # 61. Lots of other apps (some Web browsers, IDEs, etc.) still store most of their configs in flat files
[20:50] <mhwood> This is one reason I'm trying to express ConfigurationManager in terms of Configuration Service: ConfigurationService is injectable, so we can have two (or more) implementations and switch easily.
[20:50] <mhwood> My contention is that some of our configuration shouldn't be in DB tables *or* flat files, because it isn't flat or tabular.
[20:51] <tdonohue> mhwood - true
[20:51] <tdonohue> even if we were to go with DB tables, some configs would *need* to remain in flat files (esp. for example, the DB configs).
[20:52] <mhwood> I think we need to step back and ask: what's the most useful representation for our configuration (as opposed to the data which embody it). Then we may find that we need several ways to back different parts. What we need should guide what we build.
[20:52] <helix84> tdonohue: that part - "minimal config in files is necessary" is clear
[20:54] <mhwood> Actually, ignoring the structured-config issue, we could have *no* config in files. DSpace only critically depends on two things: "where's my database" and "where are my files"?
[20:54] <helix84> what i'm hearing here is a bit contradictory - there were complaints about too many configuration files and OTOH, that we want to keep config in files. Historically, we moved from a single config file to multiple files to make things more clear. See what I mean?
[20:54] <tdonohue> For what it's worth, my opinion is actually that I don't really care where the majority of the configs are (DB or files). I'm more interested in being able to change configurations *dynamically* and also be able to *edit/update (most) configs* from some sort of UI.
[20:54] <helix84> tdonohue: yes, that's also Joao's opinion
[20:55] <mhwood> If you mean my issue title, "too many configurations" means that we have two completely separate managers of configuration data, each reading the files in slightly different ways.
[20:55] <helix84> mhwood: thanks, that clears it up
[20:55] <bollini> tdonohue: I agree to... dynamically change is the key
[20:55] <helix84> mhwood: if we choose to keep cfg in files, do you see us moving to a single configuration format? is that even possible
[20:56] <mhwood> I doubt it would be comfortable. It might be *possible*.
[20:56] <mhwood> There is stuff in Properties format that should be e.g. XML, because it has structure and depth.
[20:56] <tdonohue> helix84 - most configs are in "properties" files. (unless it's something that unfortunately cannot be described that well in that format...then we use XML)
[20:57] <helix84> or should we just move property=value to DB and keep everything "structured" (+bootstrap cfg) in files?
[20:57] <mhwood> The simple key=value stuff easily moves into the DB if we wish. The rest is probably easier to keep in files.
[20:57] <bollini> our configuration files are too complex because we have chosed our custom rappresentation... now we are starting to use spring xml files I think that this is the way to follow
[20:58] <helix84> bollini: custom representation? which files in particular?
[20:58] <mhwood> Using Spring is indeed one way to represent that stuff externally. Better than to build custom schemas.
[20:58] <bollini> dspace.cfg
[20:58] <bollini> think about the plugin sintax
[20:58] <mhwood> ??? dspace.cfg is serialized Properties.
[20:58] <bollini> and the setting for any single plugin
[20:58] <mhwood> Oh, I see. Never mind.
[20:59] <bollini> dspace.cfg is a properties file but we have "our semantics" to process and understand it
[20:59] <mhwood> I agree there. That's what I'm thinking about. Plugins have complex relationships within their configuration.
[20:59] <tdonohue> yea...the plugin stuff in dspace.cfg is ugly. I agree. It works, but it's ugly
[20:59] <helix84> sorry, I don't see the problem with dspace.cfg
[20:59] <mhwood> Try configuring a crosswalk.
[20:59] <helix84> oh, you mean relationships of individual config properties
[21:00] <bollini> are you sure? have you looked to the browse configuration? how many split and string processing we are doing in the backend to understand the dspace.cfg?
[21:00] <mhwood> We have things like key = commalist of assignments (and space list of assignments)....
[21:00] <bollini> helix84: yes, definitively
[21:00] <helix84> so what would the ideal solution for that be?
[21:01] <tdonohue> helix84 -- we're talking about the plugin/crosswalk/packager configs in dspace.cfg. They are ugly, e.g.: https://github.com/DSpace/DSpace/blob/master/dspace/config/dspace.cfg#L479
[21:01] <kompewter> [ DSpace/dspace/config/dspace.cfg at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace/config/dspace.cfg#L479
[21:01] <mhwood> We have stuff encoded in the keywords, that has to be broken down and matched to parallel sets of keywords....
[21:01] <tdonohue> plugins/crosswalks/packagers should ideally be configured via Spring or similar, as bollini mentioned. Those things normally don't need to be touched by "normal users" anyhow
[21:01] <mhwood> We are bending Properties format until it begs for mercy.
[21:01] <helix84> moving those properties to a structured cfg format or splitting them up even further into more property=value pairs?
[21:02] <bollini> moving those properties in a spring xml file (not an our newly structured cfg format)
[21:02] <tdonohue> helix84 - I think you may be looking for a "single config" solution which doesn't exist. I'd split things up into several areas... for example:
[21:02] <mhwood> We could consider doing the simple actually-flat stuff now and putting the harder stuff off.
[21:03] <helix84> mhwood: agreed
[21:03] <bollini> I like minimal configuration file, we should stop to put default configuration in the files (convention over configuration)
[21:03] <mhwood> bollini++
[21:03] <helix84> bollini: so can we move *all* structured cfg to spring files? or just specific ones like plugin cfg?
[21:03] <tdonohue> bollini++
[21:03] <tdonohue> mhwood++
[21:04] <bollini> helix84: imho in the long run: all
[21:04] <mhwood> DSpace should be able to start with no configuration at all. It couldn't do much other than complain, but it could complain intelligently, tell you what it wants.
[21:04] <helix84> i'd agree with having minimal configuration files, but we currently don't have another place where users can see all the options available. Our docs surely fail to keep up with changes to code.
[21:04] <hpottinger> mhwood++ as long as it's specific
[21:05] <tdonohue> helix84 -- If more config settings move to the UI, then the UI can explain each config (just pull the comments from dspace.cfg into the UI)
[21:05] <helix84> mhwood: we could work towards ensuring that even without stopping to distribute the full configuration file
[21:06] <helix84> tdonohue: yes, that's how I imagine it
[21:06] <mhwood> I think that bollini's point is: we should not *depend* on finding the defaults in the config file.
[21:06] <helix84> mhwood: I agree, see my previous point
[21:07] <mhwood> We can still ship the file with commented defaults and lots of explanation. But DSpace should start even if the config file doesn't exist.
[21:08] <bollini> mhwood: yes and not, in some case we already manage default (specially for backward compatibility)
[21:08] <mhwood> The more administrative UI we can provide to front-end the configuration process, though, the less we have to explain in the file (if there is still a file).
[21:08] <tdonohue> It sounds like (correct me if I'm wrong) we really want to do this in several stages (and not all-at-once). (1) Make Dynamic Configuration happen (with existing configs mostly as-is in files -- something like PR #61), (2) Build a Config UI on that, (3) Move some/many configs around to more logical places (Spring, or even DB or whatever), (4) See if we can get DSpace to start without any major configs (convention over configurati
[21:09] <bollini> mhwood: ok, full configuration files can be provided but we should promote minimal configuration. So we should provide as default a dspace.cfg with only db setting and main directory
[21:09] <tdonohue> the main point being, we don't need to do everything at once...we can "stage" this out and keep improving it
[21:09] <helix84> tdonohue: yes, and (4) can be worked on right now, in parallel
[21:10] <tdonohue> right..actually several of those may be possible to do "in parallel". Ignore the numbering..that's not implying they need to be done in sequence :)
[21:10] <mhwood> So is there still a place for consolidating the existing setup?
[21:10] <helix84> mhwood: what do you mean by consilidating?
[21:10] <tdonohue> mhwood - not sure I understand that question? can you explain?
[21:11] * tdonohue notes we are obviously in "overtime" here. Great discussion though...so I'm gonna let this all continue
[21:11] <mhwood> ConfigurationService actually reads the Properties files. ConfigurationManager asks ConfigurationService for values to pass back to its callers. One object, not two, managing configuration.
[21:12] <mhwood> When we have another way of backing the config, inject that implementation instead of the current one. ConfigurationManager never changes.
[21:12] <tdonohue> I think no matter *what* we do...we still need your DS-1390 idea of consolidating everything into ConfigurationService
[21:12] <kompewter> [ https://jira.duraspace.org/browse/DS-1390 ] - [#DS-1390] DSpace has too many configurations - DuraSpace JIRA
[21:12] <mhwood> Yes, I think it is complementary to the issue of how configuration is actually stored.
[21:13] <tdonohue> mhwood: yes, exactly
[21:13] <mhwood> And that it should simplify the evolution of the configuration store.
[21:13] <helix84> I'd say yes, but I know the implementation only superficially. But you may really want to look at the code of PR #61 to see what is suggested here.
[21:13] <mhwood> I plan to.
[21:14] <bollini> I have only a concern about the configuration service, initialization time for the ConfigurationService and the ConfigurationManager are different
[21:15] * l_a_p (~chatzilla@93-63-22-159.ip25.fastwebnet.it) has left #duraspace
[21:15] <bollini> I have had use case where the configuration service was not yet fully initialized and I was forced to use the ConfigurationManager
[21:16] <tdonohue> PR #61 looks to only modify ConfigurationManager... doesn't look to touch ConfigurationService
[21:17] <tdonohue> bollini - yea, that would likely be part of moving things over to ConfigurationService. We'd need to ensure that the initialization times of each are identical. If I recall correctly, mdiggory has mentioned this as a problem in ConfigurationService as well
[21:18] <tdonohue> I've gotta head out of here shortly. It's been a good discussion today though. Sounds like we have some ideas around Configuration improvements, but we should bring this back to PR #61 (and Ds-1390 as well)
[21:18] <mhwood> Please email me any details, or log them in Jira, and I will look into that.
[21:18] <mhwood> Yes, I need to leave now too.
[21:19] <mhwood> Details of the timing issue, that is.
[21:19] <tdonohue> mhwood: I wish I had the details -- I just have a vague memory of mdiggory mentioning a possible issue there. Hopefully bollini has more details on the timing issue.
[21:19] <mhwood> Please, anything would help.
[21:19] <bollini> I will try to formalize and send a note to the mailing list
[21:20] <mhwood> Thank you.
[21:20] <mhwood> 'bye, all!
[21:20] <bollini> I need to leave too... thanks to all
[21:20] <tdonohue> mhwood: oh, mdiggory makes a vague mention at the end of this comment: https://github.com/DSpace/DSpace/pull/61#issuecomment-8115317
[21:20] <kompewter> [ Enabling Dynamic DSpace Configuration Manager by lyncodev · Pull Request #61 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/61#issuecomment-8115317
[21:20] * bollini (~chatzilla@host136-17-dynamic.53-79-r.retail.telecomitalia.it) Quit (Quit: ChatZilla 0.9.90 [Firefox 20.0.1/20130409194949])
[21:20] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[21:24] * helix84 (~a@ip4-95-82-147-170.cust.nbox.cz) has left #duraspace
[21:26] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has left #duraspace
[21:52] * PeterDie_ (~peterdiet@dhcp-140-254-148-230.osuwireless.ohio-state.edu) has joined #duraspace
[21:52] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) has left #duraspace
[21:55] * PeterDietz (~peterdiet@128.146.173.70) Quit (Ping timeout: 248 seconds)
[21:56] * PeterDie_ (~peterdiet@dhcp-140-254-148-230.osuwireless.ohio-state.edu) Quit (Ping timeout: 268 seconds)
[22:24] * ksclarke (~kevin@pdpc/supporter/active/ksclarke) Quit (Quit: Leaving.)
[22:34] * ksclarke (~kevin@pdpc/supporter/active/ksclarke) has joined #duraspace
[23:39] * ksclarke (~kevin@pdpc/supporter/active/ksclarke) Quit (Quit: Leaving.)
[23:48] * ksclarke (~kevin@pdpc/supporter/active/ksclarke) has joined #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.