Timestamps are in GMT/BST.
[0:34] * snail (~yeatesst@130.195.179.88) Quit (Ping timeout: 240 seconds)
[0:44] * snail (~yeatesst@130.195.179.88) has joined #duraspace
[0:44] * ksclarke (~kevin@adsl-39-66-159.clt.bellsouth.net) Quit (Ping timeout: 240 seconds)
[0:44] * ksclarke (~kevin@adsl-39-66-159.clt.bellsouth.net) has joined #duraspace
[1:31] * DuraLogBot (~PircBot@atlas.duraspace.org) Quit (Ping timeout: 240 seconds)
[1:31] * Disconnected.
[1:31] -lindbohm.freenode.net- *** Looking up your hostname...
[1:31] -lindbohm.freenode.net- *** Checking Ident
[1:31] -lindbohm.freenode.net- *** Found your hostname
[1:31] -lindbohm.freenode.net- *** No Ident response
[6:55] -leguin.freenode.net- *** Looking up your hostname...
[6:55] -leguin.freenode.net- *** Checking Ident
[6:55] -leguin.freenode.net- *** Found your hostname
[6:55] -leguin.freenode.net- *** No Ident response
[6:55] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:55] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:55] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[12:35] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has joined #duraspace
[13:16] * ksclarke (~kevin@adsl-39-66-159.clt.bellsouth.net) Quit (Ping timeout: 258 seconds)
[13:21] * ksclarke (~kevin@adsl-39-66-159.clt.bellsouth.net) has joined #duraspace
[13:28] * tdonohue (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) has joined #duraspace
[16:07] * gsoc_ajhall (~darkmatte@acad53201.wireless.uic.edu) has joined #duraspace
[16:27] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[16:37] * gsoc_ajhall (~darkmatte@acad53201.wireless.uic.edu) Quit ()
[16:39] * gsoc_ajhall (~darkmatte@acad53201.wireless.uic.edu) has joined #duraspace
[17:18] * mmlevitt (~quassel@96-41-77-28.dhcp.mtpk.ca.charter.com) has joined #duraspace
[17:57] * gsoc_ajhall (~darkmatte@acad53201.wireless.uic.edu) Quit ()
[18:49] * KevinVdV (~KevinVdV@d54C15567.access.telenet.be) has joined #duraspace
[18:52] * bojans (~Bojmen@91-118-57-42.dynamic.adsl-line.inode.at) has joined #duraspace
[19:20] * KevinVdV (~KevinVdV@d54C15567.access.telenet.be) Quit (Quit: KevinVdV)
[19:30] * grahamtriggs (~grahamtri@cpc2-stev6-2-0-cust333.9-2.cable.virginmedia.com) has joined #duraspace
[19:45] * KevinVdV (~KevinVdV@d54C15567.access.telenet.be) has joined #duraspace
[19:48] * robint (50c01881@gateway/web/freenode/ip.80.192.24.129) has joined #duraspace
[19:50] <tdonohue> Reminder, in about 10 mins we'll start our DSpace Developers Mtg here. Agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-04-06
[19:50] <kompewter> [ DevMtg 2011-04-06 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-04-06
[19:52] * hpottinger (80ce5cde@gateway/web/freenode/ip.128.206.92.222) has joined #duraspace
[19:58] * richardrodgers (~richardro@18.111.18.64) has joined #duraspace
[19:58] * keithgilbertson (~keithgilb@lawn-128-61-21-23.lawn.gatech.edu) has joined #duraspace
[20:00] <tdonohue> Hi all. Welcome. Time for our weekly DSpace Developers Mtg. Here's our agenda for today: https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-04-06
[20:00] <kompewter> [ DevMtg 2011-04-06 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-04-06
[20:00] <tdonohue> We'll kick things off with some more JIRA Quick Reviews. Here's the list of issues left to review: https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+resolution+%3D+Unresolved+AND+Key%3E%3DDS-765+ORDER+BY+key+ASC
[20:00] <kompewter> [ https://jira.duraspace.org/browse/DS-765 ] - [#DS-765] OAI-PMH error in ListIdentifiers - DuraSpace JIRA
[20:00] <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-765+ORDER+BY+key+ASC
[20:00] <tdonohue> First up, is issue DS-765
[20:00] <kompewter> [ https://jira.duraspace.org/browse/DS-765 ] - [#DS-765] OAI-PMH error in ListIdentifiers - DuraSpace JIRA
[20:01] <tdonohue> (NOTE -- there's quite a few in a row here that are all OAI-PMH related, reported by Claudia. It started with Ds-764 from last week, and concludes with Ds-767)
[20:02] * PeterDietz (~PeterDiet@sul272peter.lib.ohio-state.edu) has joined #duraspace
[20:03] <tdonohue> Any comments, thoughts on Ds-765? Do we have any OAI-PMH experts (or volunteers) who'd want to look into all these issues reported by Claudia? They all seem semi-related.
[20:04] <mhwood> Sounds like a problem. Do we have a precise definition of "non-disseminable" in this context?
[20:04] <richardrodgers> I guess the underlying question is how does dissemination map to OAI visibility?
[20:04] <kshepherd> morning all
[20:05] <tdonohue> I think the "non-disseminable" in Ds-765 is the same as described in DS-764
[20:05] <kshepherd> (DST is over.. gotta get up early again! :))
[20:05] <kompewter> [ https://jira.duraspace.org/browse/DS-764 ] - [#DS-764] OAI-PMH ListRecords false no result answer and missing resumptionToken - DuraSpace JIRA
[20:05] <mhwood> Good, I could use another morning.
[20:05] <kshepherd> aschweer has been doing some good work in reproducing and tracking down these problems, i think
[20:05] <kshepherd> probably a bit too early for her to be in the office though
[20:06] <tdonohue> kshepherd -- yea, I noticed andrea took on Ds-764. There's a series of OAI problems, it looks like. Currently looking at DS-765
[20:06] <kompewter> [ https://jira.duraspace.org/browse/DS-765 ] - [#DS-765] OAI-PMH error in ListIdentifiers - DuraSpace JIRA
[20:06] <tdonohue> (any idea if this is another that andrea is looking at, or interested in looking at?
[20:07] <kshepherd> it is, yeah
[20:08] <tdonohue> ok, will assume Ds-765 is being investigated by aschweer. Someone should follow up with her to be certain.
[20:08] <tdonohue> Next one then: DS-766 (another OAI-PMH one)
[20:08] <kompewter> [ https://jira.duraspace.org/browse/DS-766 ] - [#DS-766] OAI-PMH non-persistent oai identifiers - DuraSpace JIRA
[20:08] <kshepherd> tdonohue: i should be able to catch up with her today
[20:08] <kshepherd> hmm
[20:09] <kshepherd> not so sure about 766
[20:09] <kshepherd> it's true that "persistence" as a term is overused somewhat
[20:09] <kshepherd> the same could be said of canonical handle urls, bitstream urls, etc
[20:09] <tdonohue> To me, it seems like with Ds-766 should point at Handles (if a handle server is installed), otherwise should point at 'dspace.hostname'
[20:09] <richardrodgers> indeed
[20:10] <richardrodgers> relative to the harvester, the host is important as source info
[20:11] <tdonohue> that's true.
[20:11] * keithgilbertson (~keithgilb@lawn-128-61-21-23.lawn.gatech.edu) Quit (Quit: keithgilbertson)
[20:11] <tdonohue> so, do we have recommendations here? Is this a "won't fix"? Or a "needs more analysis"?
[20:12] <richardrodgers> tdonohue: the latter, I'd say
[20:12] <kshepherd> yep +1 needs more analysis
[20:12] <mhwood> Agree, it sounds like something to look into.
[20:12] * JRhoads (~jrhoads@160.10.15.22) has joined #duraspace
[20:12] <richardrodgers> I'd be curious how, e.g. Fedora repos do it....
[20:12] <kshepherd> and if we all chip in with our opinions in the comments, that won't hurt either :)
[20:12] <tdonohue> ok. Ds-766 summary: Needs more analysis, suggestions of a better way to do this. Also needs a volunteer
[20:12] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: Connection reset by peer)
[20:13] <tdonohue> (yes -- please add comments to this, and other issues. We shouldn't limit our comments just to these meetings)
[20:13] * keithgilbertson (~keithgilb@lawn-128-61-21-23.lawn.gatech.edu) has joined #duraspace
[20:13] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[20:13] <tdonohue> Next up: DS-767 (yet another OAI-PMH one)
[20:13] <kompewter> [ https://jira.duraspace.org/browse/DS-767 ] - [#DS-767] OAI-PMH verb ListIdentifiers deleted status in header - DuraSpace JIRA
[20:14] <kshepherd> richardrodgers: good idea, i can test that today
[20:14] <richardrodgers> cool, kshepherd
[20:15] <mhwood> Seems like a reasonable request.
[20:15] <tdonohue> Ds-767 sounds relatively minor, but is more of a consistency issue.
[20:15] <tdonohue> any volunteers or more thoughts on Ds-767?
[20:15] * keithgilbertson (~keithgilb@lawn-128-61-21-23.lawn.gatech.edu) Quit (Remote host closed the connection)
[20:16] * keithgilbertson (~keithgilb@143.215.141.78) has joined #duraspace
[20:16] <kshepherd> yep +1 to this idea
[20:16] * mmlevitt (~quassel@96-41-77-28.dhcp.mtpk.ca.charter.com) Quit (Remote host closed the connection)
[20:16] <tdonohue> hearing none. Ds-767 summary: Seems reasonable, needs volunteer (sounds relatively minor to fix)
[20:16] <kshepherd> i can take a look, although i wouldn't be surprised if aschweer jumps in while she's on an OAI roll :)
[20:17] <kshepherd> so i'll volunteer for now
[20:17] <tdonohue> Next up, is our much beloved DS-768.
[20:17] <kompewter> [ https://jira.duraspace.org/browse/DS-768 ] - [#DS-768] All XMLUI Error Pages respond with 200 OK, instead of 404 Not Found - DuraSpace JIRA
[20:17] <tdonohue> Ok. Ds-767 - assign to kshepherd
[20:17] <richardrodgers> agreed, sounds like nice to have if not too expensive
[20:17] <tdonohue> anyone do further research/investigation into Ds-768?
[20:18] <kshepherd> mdiggory asked a cocoon guy about the revision the patch was committed
[20:18] <kshepherd> so we could try and track it down
[20:18] <kshepherd> i checked out the cocoon 2.2 source to try and track it down via commit comments, but had no luck
[20:18] <tdonohue> +1 to tracking down this cocoon patch, if we can.
[20:18] <kshepherd> there's a reply in COCOON-2218 to mark's questoin
[20:18] <kshepherd> "Mark, I'm not entirely sure, but looking at the history I think it could've been revision 685544. Can't easily test this at the moment though..."
[20:19] <kshepherd> so that gives us a possible lead
[20:19] <kshepherd> i'll add to our comments
[20:19] <tdonohue> sounds good. volunteers to test this lead out? (or is mdiggory planning on doing so?)
[20:20] <kshepherd> well i know mdiggory and i have it on our radars
[20:20] * tdonohue remembers mdiggory is out this week. so, he actually isn't here today.
[20:20] <kshepherd> not sure if it needs assigning until we're closer to a fix..?
[20:21] <tdonohue> ok. Ds-768: kshepherd will add updates. He and mdiggory have this on their radars. One or both will bring it back to our attention as help is necessary, etc
[20:21] <tdonohue> we'll stop there for today, as we are over 20 minutes in. :)
[20:22] <tdonohue> Next up, is some GSoC Updates.
[20:22] <tdonohue> We've had some decent interest so far...not as many applications as last year (yet), but we still have a few more days left (deadline is Fri, April 8)
[20:22] <kshepherd> ooh yes, i see a few more there now :)
[20:22] * keithgilbertson_ (~keithgilb@lawn-128-61-21-23.lawn.gatech.edu) has joined #duraspace
[20:22] <tdonohue> 14 applications total (10 Dspace, 2 Fedora & 2 DuraCloud)
[20:23] <richardrodgers> repeat offenders?
[20:23] <tdonohue> a few of those 14 are not really applications though (they are essentially spam/throwaway)
[20:23] * keithgilbertson_ (~keithgilb@lawn-128-61-21-23.lawn.gatech.edu) Quit (Remote host closed the connection)
[20:23] * keithgilbertson (~keithgilb@143.215.141.78) Quit (Read error: Connection reset by peer)
[20:24] * keithgilbertson (~keithgilb@143.215.141.78) has joined #duraspace
[20:24] <kshepherd> good to see the other duraspace projects getting interest too
[20:24] <tdonohue> From last year we have one potential repeat student -- Yigang Zhou.
[20:25] <tdonohue> yep -- Fedora & Duracloud are definitely excited about that. Even though they have less applications in, both of them have a least one that looks pretty solid
[20:25] <richardrodgers> how are we on the other side - mentor supply?
[20:26] <tdonohue> If anyone is interested in Mentoring or helping vote on these applications, please request "mentorship" privileges from our GSoC site: http://www.google-melange.com/gsoc/org/google/gsoc2011/duraspace
[20:26] <kompewter> [ DuraSpace - Homepage ] - http://www.google-melange.com/gsoc/org/google/gsoc2011/duraspace
[20:26] <tdonohue> Well, we have a decent number of mentors right now. But, we could always use more. :)
[20:26] <richardrodgers> good to hear
[20:27] <kshepherd> if the proposal i'm interested in goes ahead, i'd love a co-mentor
[20:27] <tdonohue> I personally, like the idea of co-mentorship, if we can find enough mentors. Just cause that provides the student with even more feedback. But, obviously, people will still be welcome to mentor on their own as they see fit
[20:28] <tdonohue> So, I think that's all the real updates I had for GSoC. Any questions right now?
[20:29] <tdonohue> Oh, once the student application process ends on Friday, we'll have 2 weeks, until April 22, to rank & decide on which projects we want to accept.
[20:29] <tdonohue> Just to be clear, if you want to help us make that decision, I'd suggest signing up for mentor privileges: http://www.google-melange.com/gsoc/org/google/gsoc2011/duraspace
[20:29] <kompewter> [ DuraSpace - Homepage ] - http://www.google-melange.com/gsoc/org/google/gsoc2011/duraspace
[20:29] <richardrodgers> any we aren't guaranteed all the slots we ask for, right?
[20:29] <richardrodgers> any -> and
[20:30] <tdonohue> correct, we are not *guaranteed* slots, but they seem more lenient on that this year. So, we haven't had to even finalize our request for slots yet. (I think we have until April 22 to even request that).
[20:30] <kshepherd> no, but just going by gut, i suspect we won't end up in that position
[20:30] <kshepherd> given the number of applications
[20:31] <tdonohue> given the number of applications, we are on the "low end" this year. Most years, we have ~20-30 applications just for Dspace projects. This year, we only have 14 total, so far
[20:32] <tdonohue> FYI as well -- decision making on projects will be slightly different this year, as we want to ensure Fedora & DuraCloud also get projects if they want them. So, "highest vote" won't necessarily win ;) We may have to 'bargain' with Fedora/DuraCloud team (esp. for students who put in multiple apps)
[20:33] <richardrodgers> ahh, so we can internally allocate
[20:33] <kshepherd> that sounds fair
[20:33] <tdonohue> (i.e. some students have put in applications for *both* DSpace and Fedora -- obviously only one of the projects will end up being accepted)
[20:34] <richardrodgers> yep - we should definitely distribute the fun
[20:34] <tdonohue> ok. I think that's it for GSoC updates for today. Next week we can start the review process and begin to figure out which students we'd really like to work with!
[20:35] * tdonohue For any students listening in now: Thanks for your GSoC application!
[20:36] <tdonohue> Ok. next topic: "Commitment" on DSpace Services. I put "commitment" in quotes here, because I would like to also discuss whether we all feel we need to *vote*, or if we'd like richardrodgers email suggestion (from an hour ago)
[20:36] <tdonohue> I personally can see both sides here...
[20:37] <tdonohue> In some ways, a "vote" will make sure we are all "on the same page" and not doing potentially duplicative efforts (or accidentally "ignoring" ongoing efforts to change things over to Services Model)
[20:38] <tdonohue> In other ways, I understand richardrodgers point that "what wins" will inevitably just "bubble up" as we naturally accept/reject it over time
[20:38] <tdonohue> thoughts on this?
[20:39] <richardrodgers> I just worry about 'unfunded mandates'. For example, as long as I remember we voted on how important unit tests were. But until Pere did them, the sentiment didn't matter
[20:40] <mhwood> In the Services case, @mire seems to be doing them while we watch.
[20:40] * tdonohue notes that mdiggory is not here to argue for the benefits of Services and the work that he is doing around Services, but I still want to discuss this today, even if there's no "final" decision.
[20:40] * keithgilbertson (~keithgilb@143.215.141.78) has left #duraspace
[20:41] <richardrodgers> but mhwood I know Mark has invited participation...
[20:41] <richardrodgers> Mark D, I mean
[20:41] <tdonohue> richardrodgers -- although I agree to a point, I'd also point out that in a way, the idea of Services Model is more of an architectural change -- which obviously requires more approval/support than things like unit tests.
[20:41] <kshepherd> i'd like to note that my silence on services doesn't mean i'm against them, just that i'm still learning/practicing before i jump in the deep end and get told off for doing it wrong
[20:42] <kshepherd> i'm for services in principle (viewed in isolation from the async/out-of-trunk arguments)
[20:42] <mhwood> Well, we have some saying let's see how it works out, and others telling people that Services is The Way.
[20:42] <tdonohue> kshepherd -- duly noted :) Do others feel the same way? Is this still a "learning issue"? Are there folks who are just being silent cause they don't quite fully understand it, etc.?
[20:42] <robint> tdonohue:yep
[20:43] <tdonohue> (note: I will pass no judgment here -- just trying to get my mind around the issues at hand)
[20:43] <PeterDietz> I've been silent on services too, for similar reasons as kshepherd. As in, I don't plan on doing something backwards, but if its not present as to how best to do something...
[20:43] <kshepherd> https://wiki.duraspace.org/display/DSPACE/The+TAO+of+DSpace+Services is a good read
[20:43] <kompewter> [ The TAO of DSpace Services - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/The+TAO+of+DSpace+Services
[20:44] <tdonohue> +1 to reading The Tao of DSpace Services -- it at least allows you to better "get your mind" around a potential way that Services could be used
[20:44] <grahamtriggs> +1 kshepherd - whilst I have reservations on the 'internalising' of Spring, the use of Spring to deliver services is sound.... as long as it kept separate from the discussion about async releases
[20:44] <JRhoads> Yeah. I'm still trying to wrap my brain around it a bit.
[20:44] <robint> I note grahamtriggs concerns but thought mhwood asked a good question as to whether he would consider them to be showstoppers ?
[20:45] <mhwood> I've crawled over the code to document it and wasn't strongly affected either way. It seems sound in principle, could perhaps use some rework of specifics, but I don't feel a burning need to switch. I just wish there wasn't this sharp disconnect on whether we are going to do this or not.
[20:45] <tdonohue> +1 grahamtriggs on the separation of services from async releases (and I know I probably didn't help in that latest email thread -- but, the two issues are unrelated, in reality)
[20:46] <robint> tdonohue: that was my fault really, I bundled them all up in the email thread
[20:47] <tdonohue> Personally, I feel that Services is a good concept. So, as the "Tech Lead" (whatever that really means :) I'd recommend that we look into ways to commit to Services (or tweak it, if there are implementation details we aren't happy with). But, as I'm only one developer, I cannot really make this decision alone :)
[20:48] <tdonohue> So, while I'd *recommend* a commitment to Services, I think in the end, richardrodgers is right to a point: It only is truly "accepted" once it wins out amongst the majority of us.
[20:50] <tdonohue> Is there something else we can do to help this learning process? More examples of Services? Just start to refactor older "managers" into Services (like configs and plugins), so that it becomes more understandable & there's more code to draw from? Other ideas?
[20:50] <mhwood> Actually I noticed a good reason to have a replaceable Configuration service just today: I want something more expressive than Properties.
[20:51] <tdonohue> +1 mhwood -- yea, that would be a potential benefit
[20:51] <kshepherd> mhwood++
[20:54] <mhwood> grahamtriggs: anything more to say on how or where you think we ought to use Spring?
[20:54] <JRhoads> tdonohue: I think my largest issue getting a firm hand on services is trying to separate the Services idea from the Domain Model Discussion, and also from the Async Release discussion.
[20:55] <mhwood> I think that Services sits under those.
[20:56] <tdonohue> JRhoads -- they do tend to get "muddled" at times. But, in reality, they are all separate proposals/concepts. E.g. If we really wanted to we could implement Services without Async or suggested Domain Model changes, etc.
[20:56] <grahamtriggs> not that I haven't said already - just that Spring should be on the outside, as part of the application bootstrap, not buried inside a service manager. It's more flexible, and reduces the amount of code we have to maintain
[20:58] <tdonohue> grahamtriggs: do you have some examples of that written up somewhere? for instance, examples of where you see things could be simplified, etc.?
[20:58] <mhwood> Spring should instantiate the kernel instead of the other way around?
[20:59] <grahamtriggs> imho, the kernel should disappear. It's a flawed and unnecessary implementation
[21:00] <tdonohue> grahamtriggs -- I'd be interested to see a counter proposal of your implementation ideas (as I think it'd make for good discussion, and maybe even help us all learn).
[21:00] <tdonohue> grahamtriggs -- any way to convince you to write up your ideas in more details on either wiki or dspace-devel?
[21:01] * tdonohue is willing to bribe grahamtriggs with a beer at OR11, if it helps ;)
[21:01] <mhwood> I will admit feeling more than once that the kernel is one of those classes I only need because it gives me access to another class that will give me access to the class thatI actually wanted.
[21:02] <richardrodgers> I'll do the next round :)
[21:02] <grahamtriggs> I'm not sure there is anything to write up that would make things any clearer - it probably needs a working example to be created. (the whole point is that this should be so bloody simple that it is virtually non-existant)
[21:03] <tdonohue> right, grahamtriggs. I guess, by "writeup", I meant some sort of code example with explanation. Whether or not it actually needs to be fully "working", I wasn't sure.
[21:03] <mhwood> Let me see: kernel disappears. ServiceManager reduced to handing out references to core services wired in by Spring and others which declare interest in providing service later -- it 's just a holder for a list.
[21:04] <grahamtriggs> It's not so much the convincing, as inventing a whole new time continuum that's needed
[21:07] <tdonohue> hmm... I didn't quite understand it as a "whole new time continuum". Rather just a slightly different implementation idea, which I thought (though maybe I'm wrong) could be semi-represented through some sort of pseudo-code examples, etc.
[21:07] <richardrodgers> Sorry, but I have to run for now. Thanks all
[21:07] * tdonohue realizes we're already running over time here...
[21:07] <kshepherd> cheers richardrodgers
[21:07] * richardrodgers (~richardro@18.111.18.64) Quit (Quit: richardrodgers)
[21:07] <JRhoads> I have to run as well. Thank you.
[21:08] <grahamtriggs> mhwood: ServiceManager is a 'BeanFactoryAware' pojo, that initialises a static reference to the factory on creation, that can sub sequently be use to hand out services via static methods (to legacy code)
[21:08] <kshepherd> cheers JRhoads as well ;)
[21:08] * JRhoads (~jrhoads@160.10.15.22) Quit (Quit: Leaving)
[21:09] <tdonohue> It sounds like, we're still at a bit of a slight impasse. Perhaps, we keep moving forward with Services as a general concept, and just see how it starts to play out, and implement where we can find areas that it can add immediate benefits (like potentially configuration benefits pointed out by mhwood)?
[21:10] <tdonohue> though, I'd still like to try and extract out grahamtriggs ideas a bit more, mix them around, and decide if there's more "refactoring" necessary of Services as they exist now..
[21:10] <mhwood> Ultimately I just want to know what I'm expected to use, if I write something new. We have two answers right now.
[21:11] <tdonohue> To answer that: Currently, there are no services for most things, so obviously you *cannot* use services, unless you create them. However, if you find an area where Services may help/provide benefit, I'd highly encourage implementing one if your time allows.
[21:12] <tdonohue> i.e. a recommendation towards Services, while at the same time pointing out that "if they don't yet exist", you are welcome to continue with the current ways of doing things.
[21:12] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: Connection reset by peer)
[21:12] <KevinVdV> The place where I know some services are used (so you can at least look for an example) is in Discovery if you want to see what they can do for you
[21:13] <mhwood> I was thinking more of the core services. We have two sources of configuration. What do we tell people about that.
[21:13] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[21:13] <mhwood> I should have said "providers", not "sources".
[21:15] <tdonohue> mhwood -- I think that's one of those "gray" areas. Currently, "configuration" is duplicated. Though, I think obviously it shouldn't be. I'd recommend moving towards the Service implementation in that case, but again -- it's currently still a recommendation & not a requirement.
[21:15] <tdonohue> I think it would *become* a requirement, once the Configuration Service is more widely integrated into the core API (dspace-api). At which point, the old ConfigurationManager likely has to become obsolete.
[21:16] * keithgilbertson (~keithgilb@lib-kgilbertson.library.gatech.edu) has joined #duraspace
[21:16] <mhwood> I guess we're not ready to commit "yes" or "no". What needs to happen before we can commit?
[21:16] <PeterDietz> KevinVdV: would it be something like: https://github.com/DSpace/DSpace/blob/master/dspace-discovery/dspace-discovery-provider/src/main/resources/spring/spring-dspace-addon-discovery-services.xml and https://github.com/DSpace/DSpace/blob/master/dspace-discovery/dspace-discovery-xmlui-api/src/main/java/org/dspace/app/xmlui/aspect/discovery/SiteRecentSubmissions.java#L112
[21:16] <kompewter> [ dspace-discovery/dspace-discovery-provider/src/main/resources/spring/spring-dspace-addon-discovery-services.xml at master from DSpace/DSpace - GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace-discovery/dspace-discovery-provider/src/main/resources/spring/spring-dspace-addon-discovery-services.xml
[21:17] <kompewter> [ dspace-discovery/dspace-discovery-xmlui-api/src/main/java/org/dspace/app/xmlui/aspect/discovery/SiteRecentSubmissions.java at master from DSpace/DSpace - GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace-discovery/dspace-discovery-xmlui-api/src/main/java/org/dspace/app/xmlui/aspect/discovery/SiteRecentSubmissions.java#L112
[21:17] <KevinVdV> Yep that is it
[21:18] <tdonohue> mhwood: code/patch, probably. We don't have code to review to say "yes", this new implementation of dspace-api with ConfigurationService is better than using the old ConfigurationManager. Therefore, we vote to release this newly refactored dspace-api in 1.8 (or whatever version) and retire ConfigurationManager
[21:19] <tdonohue> that's just my opinion, mhwood. It sounds like most people are uncomfortable with voting right now, as there's not enough code examples / understanding. Therefore, it probably wouldn't do much good to vote today, until we have code/examples to formally approve
[21:19] <mhwood> Agreed, there is no consensus.
[21:20] <mhwood> I was hoping to do *something* to break the loop. We talk about Services and then nothing happens. Lather, rinse, repeat.
[21:21] <tdonohue> well -- one way to break the cycle is to write more code. Build something in Services, and post as an example for people to learn from / comment on / etc
[21:21] <robint> tdonohue: +1. Tkes us back to richards point
[21:21] <tdonohue> I think the more individual developers start to "accept" services, the more likely we'll all start to accept it.
[21:21] <robint> tkes/takes
[21:22] <tdonohue> yep. exactly. it's basically richardrodgers point, just worded a bit differently :)
[21:22] <mhwood> Do we have consensus that this is something we should try? That the problems we see are fixable in a reasonable amount of time?
[21:22] <robint> Got to rush. Don't know about others but the discussion(s) do help me get there. Cheers
[21:23] * robint (50c01881@gateway/web/freenode/ip.80.192.24.129) Quit (Quit: Page closed)
[21:23] <kshepherd> mhwood: don't wait for consensus, just do it ;)
[21:23] <tdonohue> I'd say +1 to more code in Services. Especially more Configuration in Services. But, I also agree with kshepherd. We need people to just do it.
[21:23] <kshepherd> im not stalling on trying because i'm not convinced it's a good idea
[21:23] <tdonohue> I'd encourage us *all* to just start trying out Services. Try to break the cycle
[21:24] <kshepherd> i'm stalling on trying because i suspect i'm too stupid to do it properly
[21:25] <tdonohue> we really should wrap up here. but, this discussion has been very good (yes, I know it's still just "discussion", but at least we seem to have a general consensus that "more code" may be a way forward)
[21:25] <mhwood> I promised some time ago to use Services when I had an opportunity, and I will. I'm a bit concerned about the disconnect over whether the switch to Services is a done deal.
[21:25] <PeterDietz> Say for instance, I really hated solr, and thought that DSpace should not use it, then services allows me to find an alternative (perhaps elastic search), then I can go ahead and implement a whole bunch of POJO's to get the job done, and to turn on my fixed solution, I edit how things are wired up in something like spring-dspace-discovery-services.xml
[21:26] <tdonohue> mhwood -- I'd say it's basically a "done deal" as Services is already in 1.6 and 1.7 (and even more so in things like Discovery). So, it's at least much further along towards acceptance than anything else may be
[21:26] <mhwood> I suppose the question is why we need Services framework at all, if we have Spring anyway.
[21:26] <KevinVdV> Well correct me if I'm wrong but doesn't this make it easier so that not everybody would have to write their own spring code to read in their spring files ?
[21:27] * bojans (~Bojmen@91-118-57-42.dynamic.adsl-line.inode.at) Quit (Remote host closed the connection)
[21:27] <PeterDietz> so for me its not so much voting, but wanting to improve something so much, that it makes sense to wire in a better solution than to try to nurse along the existing. or in the case of configuring things. one could configure to use s3 instead of file-system assetstore (perhaps that one misses the point)
[21:27] <mhwood> ??? Spring reads Spring files.
[21:29] <tdonohue> mhwood -- I think that's a fine question to ask (Services vs. straight Spring). But, we probably need more examples of pros/cons of each (which I'd encourage us to analyze).
[21:29] <tdonohue> (if mdiggory was here today, he may have more to say in that comparison..)
[21:30] <tdonohue> maybe ask that specific question on dspace-devel?
[21:30] <mhwood> OK, I need to go write something.
[21:30] <grahamtriggs> KevinVdV: Nobody has to write their own Spring code to read Spring files. You write Spring files, gather them all up and pass them to a Spring factory. Here, it's just a context-param, and a Spring context listener: http://scm.dspace.org/svn/repo/modules/webmvc/trunk/freemarkerui-webapp/src/main/webapp/WEB-INF/web.xml
[21:31] * tdonohue mentions, if you need to head out, feel free. I know this meeting is way over time, but don't really want to interrupt this discussion.
[21:31] <mhwood> _Spring in Action_, 2/3, pp. 494-5
[21:31] <mhwood> 2/e
[21:33] * keithgilbertson (~keithgilb@lib-kgilbertson.library.gatech.edu) Quit (Quit: keithgilbertson)
[21:33] <tdonohue> grahamtriggs: So, is FreemarkerUI work a good example of "straight Spring", versus the usage of "Services" in Discovery?
[21:34] <grahamtriggs> Kind of. Note that it isn't actually starting any DSpace services that way (it's still bootstrapping a 'kernel' through a listener) - and this is actually a big drag for Freemarker / WebMVC - as I can't inject DSpace services into controllers, etc.
[21:34] <tdonohue> right..just noticed that it is using the kernel
[21:35] <grahamtriggs> If my context param also just included references to all the 'core' service configuration files that I needed, then they would be created in the same factory, and I would be able to inject services into the Controllers
[21:36] <tdonohue> ok, I see what you mean
[21:39] <mhwood> Sorry, I have to go. Lots to think about & do. Will check back to see further discussion. Thanks!
[21:39] <tdonohue> As chat has slowed here, I'm going to officially "close" the meeting. But, feel free to stick around here, if you want to continue these discussions (I'll be around for a while still)
[21:39] <PeterDietz> i gotta run too
[21:39] <grahamtriggs> I'm off to bed :)
[21:39] <KevinVdV> Going to bed now quite late here to
[21:40] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has left #duraspace
[21:40] * PeterDietz (~PeterDiet@sul272peter.lib.ohio-state.edu) has left #duraspace
[21:40] * KevinVdV (~KevinVdV@d54C15567.access.telenet.be) Quit (Quit: KevinVdV)
[21:40] * grahamtriggs (~grahamtri@cpc2-stev6-2-0-cust333.9-2.cable.virginmedia.com) Quit (Quit: grahamtriggs)
[21:44] * hpottinger (80ce5cde@gateway/web/freenode/ip.128.206.92.222) Quit (Quit: Page closed)
[22:00] * ksclarke (~kevin@adsl-39-66-159.clt.bellsouth.net) Quit (Ping timeout: 252 seconds)
[22:07] * tdonohue (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) has left #duraspace
[22:19] * ksclarke (~kevin@adsl-39-66-159.clt.bellsouth.net) has joined #duraspace
[22:57] * gsoc_ajhall (~darkmatte@acad55102.wireless.uic.edu) has joined #duraspace
[23:27] * ksclarke (~kevin@adsl-39-66-159.clt.bellsouth.net) Quit (Ping timeout: 240 seconds)
[23:44] * ksclarke (~kevin@adsl-39-66-159.clt.bellsouth.net) has joined #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.