Timestamps are in GMT/BST.
[0:01] * alxp (~aoneill@99-105-58-164.lightspeed.sntcca.sbcglobal.net) Quit (Quit: alxp)
[0:12] * stuartlewis (~stuartlew@s-lewis.itss.auckland.ac.nz) Quit (Quit: stuartlewis)
[0:29] * stuartlewis (~stuartlew@gendiglt02.lbr.auckland.ac.nz) has joined #duraspace
[2:22] * snail (~stuart@130.195.179.88) has joined #duraspace
[3:44] * stuartlewis (~stuartlew@gendiglt02.lbr.auckland.ac.nz) Quit (Quit: stuartlewis)
[3:58] * ThomasAJohnson (~tom@24-119-231-22.cpe.cableone.net) has joined #duraspace
[4:02] * ThomasAJohnson (~tom@24-119-231-22.cpe.cableone.net) Quit (Remote host closed the connection)
[4:06] * ThomasAJohnson (~tom@24-119-231-22.cpe.cableone.net) has joined #duraspace
[5:17] * krnl_ (Andrius@193.219.34.106) Quit (Ping timeout: 255 seconds)
[5:18] * krnl_ (Andrius@193.219.34.106) has joined #duraspace
[5:23] * ksclarke (~kevin@adsl-39-91-54.clt.bellsouth.net) Quit (Quit: Leaving.)
[5:57] * Tonny_DK (~thl@130.226.36.117) has joined #duraspace
[6:35] -card.freenode.net- *** Looking up your hostname...
[6:35] -card.freenode.net- *** Checking Ident
[6:35] -card.freenode.net- *** Found your hostname
[6:35] -card.freenode.net- *** No Ident response
[6:35] [frigg VERSION]
[6:35] * DuraLogBot (~PircBot@duraspace.org) has joined #duraspace
[6:35] * Topic is 'Welcome to DuraSpace - This channel is logged - http://duraspace.org/irclogs/'
[6:35] * Set by cwilper on Tue Jun 30 20:32:05 UTC 2009
[7:42] * Tonny_DK (~thl@130.226.36.117) Quit (Ping timeout: 245 seconds)
[7:53] * Tonny_DK (~thl@130.226.36.117) has joined #duraspace
[8:08] * scottatm (~scottatm@adhcp136.evans.tamu.edu) Quit (Ping timeout: 265 seconds)
[10:53] * grahamtriggs (~graham@62.189.56.2) has joined #duraspace
[12:18] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has joined #duraspace
[13:15] * Tonny_DK (~thl@130.226.36.117) Quit (Quit: Leaving.)
[13:16] * Tonny_DK (~thl@130.226.36.117) has joined #duraspace
[13:21] * scottatm (~scottatm@adhcp136.evans.tamu.edu) has joined #duraspace
[13:21] * tdonohue (~tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has joined #duraspace
[13:27] * ksclarke (~kevin@adsl-39-91-54.clt.bellsouth.net) has joined #duraspace
[13:41] * Tonny_DK (~thl@130.226.36.117) Quit (Quit: Leaving.)
[13:42] * Tonny_DK (~thl@130.226.36.117) has joined #duraspace
[13:47] * Tonny_DK (~thl@130.226.36.117) Quit (Quit: Leaving.)
[13:48] * Tonny_DK (~thl@130.226.36.117) has joined #duraspace
[14:01] * Tonny_DK (~thl@130.226.36.117) Quit (Quit: Leaving.)
[14:34] * ThomasAJohnson (~tom@24-119-231-22.cpe.cableone.net) Quit (Ping timeout: 276 seconds)
[14:39] * ThomasAJohnson (~tom@216.160.210.151) has joined #duraspace
[14:49] * tdonohue (~tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has left #duraspace
[14:53] * tdonohue (~tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has joined #duraspace
[16:07] * alxp (~aoneill@99-105-58-164.lightspeed.sntcca.sbcglobal.net) has joined #duraspace
[16:17] * grahamtriggs (~graham@62.189.56.2) Quit (Quit: Leaving.)
[18:54] * grahamtriggs (~grahamtri@cpc2-stev6-2-0-cust333.9-2.cable.virginmedia.com) has joined #duraspace
[19:07] * ThomasAJohnson (~tom@216.160.210.151) Quit (Ping timeout: 260 seconds)
[19:14] * ThomasAJohnson (~tom@24-119-231-22.cpe.cableone.net) has joined #duraspace
[19:46] * PeterDietz (~PeterDiet@ACK5859s3.lib.ohio-state.edu) has joined #duraspace
[19:55] * cccharles (~user@131.104.62.55) has joined #duraspace
[19:56] * dilbertson (~keith-noa@lib-kgilbertson.library.gatech.edu) has joined #duraspace
[19:56] * ksclarke (~kevin@adsl-39-91-54.clt.bellsouth.net) Quit (Ping timeout: 265 seconds)
[19:57] * robint (5229fd08@gateway/web/freenode/ip.82.41.253.8) has joined #duraspace
[19:59] <tdonohue> DSpace Dev Mtg starting here in just a few minutes. Agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2010-10-13
[20:00] * stuartlewis (~stuartlew@s-lewis.itss.auckland.ac.nz) has joined #duraspace
[20:00] * 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:00] * richardrodgers (~richardro@pool-96-237-109-32.bstnma.fios.verizon.net) has joined #duraspace
[20:01] <tdonohue> Ok all -- looks like it's about time to get started. JIRA review is up first
[20:01] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[20:01] <tdonohue> Here's the recent JIRA issues: http://jira.dspace.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=10020&resolution=-1&created%3Aprevious=-13w&assigneeSelect=&sorter/field=created&sorter/order=ASC we'll start with DS-638
[20:01] * mdiggory (~mdiggory@ip72-199-217-116.sd.sd.cox.net) has joined #duraspace
[20:01] * HardyPottinger (80ce8627@gateway/web/freenode/ip.128.206.134.39) has joined #duraspace
[20:01] <tdonohue> check files on input for viruses, and verify file format : http://jira.dspace.org/jira/browse/DS-638
[20:02] <tdonohue> richardrodgers -- I had assumed this was a complete overlap with your CurationSystem work -- is that correct?
[20:02] <richardrodgers> tdonohue: yes, we have both virus (done) and format id (inworks)
[20:03] <richardrodgers> They ought to be a bit more flexible than approach of DS-638, in that they can be performed out of UI (any means of ingest, in workflow, etc)
[20:04] <tdonohue> Ok -- so, I'm assuming we should keep this open in case code is a useful reference, or it becomes "obsolete"
[20:04] <tdonohue> "or *until* it becomes obsolete" (should that happen)
[20:04] <richardrodgers> yes, keep open I'd say
[20:04] <tdonohue> ok...we'll just move on then, and leave DS-638 open & assigned to richardrodgers
[20:04] <grahamtriggs> do we not have some kind of archive status?
[20:05] <tdonohue> what do you mean by that? obviously all issues are kept forever
[20:06] <richardrodgers> I guess grahamtriggs means a status so that we don't have to review it with the others...
[20:06] <mhwood> in-progress?
[20:06] <tdonohue> well, we could create on, if we wanted. we do have an 'in-progress' status
[20:07] <tdonohue> we have: "Received -> Open -> In Progress -> Resolved -> Closed -> ReOpened" We can add more statuses if we found a need.
[20:07] <grahamtriggs> what I mean, is that we should draw a line under it to say that we won't be taken any further, but it's there if people want it. 'Open' makes it look like it's up for future consideration
[20:08] <mhwood> Closed: fixed a different way
[20:09] <tdonohue> that would be an idea -- we could have a different "Resolution" type. Closed, Resolution = "fixed a different way" as mark suggests
[20:10] <grahamtriggs> yes... closed with an appropriate reason seems ok... although I'm not sure how we would encourage discoverability of patches for users of 'previous' versions (ok, that's a tangential issue...)
[20:11] <PeterDietz> minor case, a comment might be good enough, "This idea will be implemented by DS-1234".
[20:11] <mhwood> There is already related/relates-to for that.
[20:11] <tdonohue> yea -- and linking them together as "related" also helps
[20:12] * grahamtriggs thinks tdonohue will appreciate not doing that until after tomorrow though :)
[20:12] <tdonohue> Ok -- after the JIRA migration (tomorrow), I can minimally add a new custom "reason" for this sort of thing. We can make it better discoverable by linking and commenting
[20:12] <tdonohue> let's move on for now
[20:12] <tdonohue> Interal System Error when browsing with wrong argument : http://jira.dspace.org/jira/browse/DS-640
[20:12] <PeterDietz> looks like I've duplicated this with: http://jira.dspace.org/jira/browse/DS-684
[20:13] * ksclarke (~kevin@adsl-39-91-54.clt.bellsouth.net) has joined #duraspace
[20:13] <tdonohue> Ok, we need to mark one as a dupe then
[20:14] <tdonohue> any volunteers to implement? This would be good to fix for 1.7 (in my opinion)
[20:14] <richardrodgers> Probably should 404?
[20:14] * sandsfish (~sandsfish@18.111.26.116) has joined #duraspace
[20:14] <mhwood> Reporter says there is a patch, but didn't attach one.
[20:14] <stuartlewis> 404 sounds good.
[20:14] <tdonohue> +1 -- yea, 404 would probably be appropriate
[20:14] <stuartlewis> Assign to me if you want.
[20:15] <tdonohue> Ok DS-640 - Assign to stuartlewis for 1.7. Should return 404 (mark DS-684 as a dupe and close)
[20:15] <grahamtriggs> -1 on 404... I think.... remember, it's the same base url (with parameters) as the valid pages. Will 404 have consequences?
[20:15] <mhwood> I've been meaning to ask: how do we get contact information for issue reporters, so we can ask for more details etc?
[20:15] <tdonohue> mhwood -- if you add a comment to an issue, it will email them
[20:16] <richardrodgers> alternate suggestion grahamtriggs ?
[20:16] <mhwood> Hah, of course. Thanks.
[20:16] <grahamtriggs> Friendly message - 'No such browse' ?
[20:17] <tdonohue> yea -- that could be a good point, grahamtriggs. Not sure if all search engines will treat those as separate pages (as they are just parameterized)
[20:18] <richardrodgers> I'm a little worried about the search engine case - could expand the URL space searched....
[20:19] <richardrodgers> but I don't know enough to say one way or another
[20:19] <PeterDietz> then maybe 301 to default browse
[20:19] <tdonohue> Or, it could just send you to a page listing all the valid browse options?
[20:21] <tdonohue> suggest that we have stuartlewis investigate options and suggest a route -- 404, friendly error, etc
[20:21] <stuartlewis> xmlui for /browse/ returns 404 and doesn't seem to cause any harm
[20:22] <stuartlewis> Actually, returns 200, but message of page not found
[20:22] <mhwood> Ugh, that 200 needs fixing.
[20:22] <grahamtriggs> but then http://demo.dspace.org/xmlui/browse/?type=title doesn't return a browse page either
[20:23] <tdonohue> yea -- I think doing the same as http://demo.dspace.org/xmlui/browse/?type=SomethingNotIndexed should be fine
[20:24] <stuartlewis> But what http status code?
[20:24] <tdonohue> oh, but without the slash is an error still: http://demo.dspace.org/xmlui/browse?type=SOMETHINGNOTINDEXED
[20:24] <stuartlewis> 404, or 200
[20:24] <mdiggory> http://www.google.com/search?sourceid=chrome&ie=UTF-8&q=dspace+browse#sclient=psy&hl=en&safe=off&q=+browse+site:http%3A%2F%2Fdspace.knust.edu.gh%2F&aq=f&aqi=&aql=&oq=&gs_rfai=&pbx=1&fp=5a996d56de453056
[20:24] * ThomasAJohnson (~tom@24-119-231-22.cpe.cableone.net) Quit (Ping timeout: 265 seconds)
[20:24] <mdiggory> different parameters = different hits
[20:24] <stuartlewis> mdiggory: Isn't that < 1.5 browse?
[20:24] <grahamtriggs> tdonohue: yes, because any url that includes the slash gets the not found - even when you specify a valid type (ie. title)
[20:24] <mhwood> Should not be 200 if it's an incorrect request.
[20:25] <tdonohue> I thought we had another JIRA issue already open around the 200 vs. 404 issues in XMLUI?
[20:25] <mhwood> Yes, from way back, dependent on Cocoon problems that they never fix.
[20:25] <mdiggory> don't know I was just huntingfor an example of browse indexed in google still
[20:27] <PeterDietz> yeah they have different results for: dspace/browse-date and dspace/browse-date?order=oldestfirst in google
[20:27] <mdiggory> http://www.google.com/search?q=browse++Nuclear+site%3Ahttp%3A%2F%2Fdspace.mit.edu
[20:27] <mdiggory> Mit still does it
[20:28] <tdonohue> ok, maybe we don't have a 200 v. 404 JIRA issue opened -- I thought we did though, as I recall this discussion coming up recently
[20:28] <grahamtriggs> I think we should err on the side of caution and say that if we need a path to return valid documents for some parameters, then it should never return 404 for any invalid parameters
[20:29] <mhwood> Hmmm, well, what's HTTP for "invalid parameters"?
[20:29] <PeterDietz> 400
[20:29] <PeterDietz> Bad Request
[20:29] <mdiggory> more specifically, for just /browse? http://www.google.com/search?q=browse++Nuclear+site%3Ahttp%3A%2F%2Fdspace.mit.edu%2Fbrowse
[20:29] <stuartlewis> Sounds sensible - so in this case, what should the response be? "200, sorry, invalid browse"
[20:30] <PeterDietz> its a client error that they gave you bad input
[20:30] <tdonohue> yea -- 400 Bad Request is probably the right one for bad params.
[20:30] <tdonohue> "400, Sorry, invalid browse" seems better
[20:30] <tdonohue> http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
[20:30] <mdiggory> true
[20:30] <mhwood> We should not return OK for an uninterpretable request. A well-formed request which finds nothing should return OK.
[20:30] <stuartlewis> It all depends on google et al differentiating between pages with query string parameters. Surely they do? So many sites work that way.
[20:31] <stuartlewis> 404 OK for some parameters, 200 for others.
[20:31] <sandsfish> what we've done is prohibit invalid browse URL processing from adding anything the DRI body, which in turn activates the Manakin PageNotFound transformer.
[20:31] <tdonohue> Google does differentiate between pages w/query string params. Top 2 results here are same, except for querystring: http://www.google.com/search?q=browse++Nuclear+site%3Ahttp%3A%2F%2Fdspace.mit.edu
[20:32] <grahamtriggs> what about proxies?
[20:32] * mbklein (~mbklein@pdpc/supporter/professional/mbklein) has joined #duraspace
[20:33] <mhwood> We're 35 minutes in. Take this topic to the dev list?
[20:33] <tdonohue> ok -- we're at 30 mins :) any final decisions, or should we take ithis to email?
[20:33] <tdonohue> yea, thanks mhwood :)
[20:33] <stuartlewis> I'll summarise options on JIRA and transfer to dspace-devel
[20:33] <tdonohue> thanks stuartlewis, sounds good
[20:34] <tdonohue> Moving on to topic #2 -- Suggested 'dspace-test' changes.
[20:34] <tdonohue> It has been recommended by grahamtriggs that we should move the 'dspace-test' Unit Tests directly into the 'dspace-api' module (as they all relate directly to that API, and it brings the tests closer to the code they test)
[20:34] <tdonohue> Pere has refactored code to move 'dspace-test' contents into 'dspace-api'. He can commit it if we approve these changes.
[20:35] <mdiggory> Big question, does it introduce a dependency on JSPUI?
[20:35] <tdonohue> dspace-test? no -- it only tests stuff in dspace-api, as far as I'm aware
[20:35] <grahamtriggs> didn't see anything in there that used JSPUI
[20:35] <mdiggory> <dependency>
[20:35] <mdiggory> <groupId>org.dspace</groupId>
[20:35] <mdiggory> <artifactId>dspace-jspui-api</artifactId>
[20:35] <mdiggory> </dependency>
[20:35] <mdiggory> is in the original dspace-test
[20:35] <richardrodgers> yes, what additional dependencies are there, if any?
[20:36] <grahamtriggs> Looking at the code, I don't think there is anything that actually makes use of that dependency
[20:37] <mdiggory> As long as that goes away, I am comfortable with merging them
[20:37] <tdonohue> I just pulled out the odd 'dspace-jspui-api' dependency in its pom.xml, and it still built properly
[20:37] <grahamtriggs> richardrodgers: it shouldn't introduce any dependencies that aren't given a test scope (so wouldn't be required by any artefacts produced)
[20:38] <mhwood> Tests belong next to their subjects. It made sense to have a separate project while in development, but now that the framework and initial tests are accepted, I agree that they should move.
[20:39] <richardrodgers> I have no objection, then
[20:39] <grahamtriggs> mdiggory: agreed, absolutely don't want to make dependencies across the project layers... if there had been any JSPUI tests in there, I would propose in the first instance to drop them to make the merge happen, and secondly to find a different solution that didn't use a dangling test project
[20:39] <mhwood> When tests land for other modules, having them all piled into one project will introduce dependencies we might not want, right?
[20:40] <mdiggory> correct mhwood very correct
[20:40] <tdonohue> so, as long as we remove that odd JSPUI pseudo-dependency, are we all in agreement to move all existing Unit Testing to 'dspace-api'?
[20:40] <mhwood> +1
[20:40] <grahamtriggs> more importantly, they should be testing the project before the artefact is produced - not allow you to deploy an artefact and then say after... 'err, you kinda got that wrong'
[20:41] <mhwood> Good point.
[20:41] <tdonohue> +1 as well...others?
[20:41] <dilbertson> +1
[20:41] <grahamtriggs> and it would be a nightmare to maintain for refactoring ,etc
[20:41] <richardrodgers> +1
[20:41] <PeterDietz> +1
[20:41] <stuartlewis> Sounds fine to me +1 (just surprised that this wasn't noted when everyone first voted for its inclusion)
[20:42] <tdonohue> Ok -- sounds like this route is approved. Stuart, would you give Pere the go ahead? (Yea -- we overlooked this obviously the first time through -- good we caught before 1.7 though)
[20:43] <stuartlewis> Sure - will work with him to get it committed.
[20:43] <tdonohue> Ok -- on to 1.7 discussions
[20:44] <PeterDietz> Hi All, we need all the outstanding issues/features to be developed, feedbacked, and committed
[20:44] <mhwood> Are there any comments on the suggested updates to prerequisite software? Any suggestions about updating Oracle version?
[20:44] <tdonohue> I wanted to put in a plug to look at richardrodgers Curation Framework closely (if we want this in 1.7, we need to review & approve very soon): https://wiki.duraspace.org/display/DSPACE/CurationSystem
[20:44] <mhwood> See DS-618
[20:46] <dilbertson> Shall we put some virus -infected files in with the unit test framework for curation testing?
[20:46] <tdonohue> mhwood -- I thought your recommendations looked good for DS-618, though I'm not sure about Oracle either (we may need to track down an Oracle user in community)
[20:46] <richardrodgers> yes, please have a look, and write yourself a task or 2.
[20:46] <snail> dilbertson: there are some 'dummy' viruses for testing
[20:47] <dilbertson> snail: thanks, better idea
[20:47] <snail> http://www.eicar.org/anti_virus_test_file.htm
[20:47] <richardrodgers> I will award prizes to the most creative (as judged by committers):
[20:48] <tdonohue> I'll also mention that I'd like to see Richard's CurationSystem work into 1.7, as I think it would also provide a way to kick off AIP generation via the Admin UI (rather than just commandline).
[20:49] <tdonohue> though -- again, we need to all review this, and make a decision on whether we agree for it in 1.7. Also, if we want it in *both* UIs, I think we still need a JSPUI implementation (is that correct, richardrodgers?)
[20:49] <richardrodgers> Correct, branch has only XMLUI for now
[20:50] * cccharles_ (~cccharles@bas5-kitchener06-1096664917.dsl.bell.ca) has joined #duraspace
[20:50] <tdonohue> Any other thoughts on this? Do we have time to review this before our Oct 22 deadline?
[20:51] <PeterDietz> re:parity.. I thought we had agreed that parity isn't required but not to do something that would prevent parity
[20:52] <richardrodgers> PeterDietz: I think that's right - 'neutrality', rather than 'parity'
[20:52] <tdonohue> in my opinion, parity is not "required" (we already don't truly have it) -- was just pointing out there isn't a JSPUI implementation yet
[20:52] <mdiggory> but changes to the dspace-api should not cause JSPUI to fail to work correctly.
[20:54] <richardrodgers> agreed, certainly
[20:54] <tdonohue> obviously -- yes
[20:54] <PeterDietz> ok, I would say if curation is stable then it can be considered for inclusion, I'll take a look at it
[20:55] <PeterDietz> (I'm using the word considered loosely)
[20:55] <PeterDietz> Code Freeze is 9 days away
[20:55] <richardrodgers> we did a round of testing, but I'm sure it could use more exercise
[20:55] <tdonohue> yep. Are their other big projects folks are working on getting into 1.7 before code freeze?
[20:56] <PeterDietz> Any other 1.7 updates people would like to share? Status on works in progress, issues with progress that you would like to share
[20:56] * cccharles_ (~cccharles@bas5-kitchener06-1096664917.dsl.bell.ca) has left #duraspace
[20:56] <HardyPottinger> I'm asking our DBA for recommendation on Oracle version
[20:57] <mhwood> Thanks!
[20:57] <tdonohue> richardrodgers -- whatever happened with the MIT CC Licensing code? is that going into 1.7, or is that delayed?
[20:57] <richardrodgers> No, that is essentially ready tdonohue
[20:58] <tdonohue> "essentially ready" = will make it before code freeze? :)
[20:58] * 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:58] <richardrodgers> sure thing!
[20:58] <grahamtriggs> I have three patches on JIRA that can go into 1.7 - 694, 695, and 697
[20:59] <richardrodgers> (I meant doc primarily)
[21:01] <dilbertson> also DS-677 on JIRA - patch should still be fine with the 695 change?
[21:02] <tdonohue> ok -- well, we are at top of hour.
[21:02] <mdiggory> I wanted to followup with the async work, discovery and another contributionplanned by @mire.
[21:02] <tdonohue> dilbertson -- DS-677 looks like an obvious bug fix, and can probably just be committed (assuming you ran some tests, obviously!)
[21:03] <tdonohue> mdiggory -- go ahead
[21:04] <dilbertson> tdonohue: yes
[21:04] <mdiggory> Mostly, we had been planning an improved simple theme for Manakin before the discussion was launched in dspace-tech. I've been told that we are accelerating that effort now
[21:04] <tdonohue> good to hear :)
[21:04] <grahamtriggs> ahh... DS-677... this is a tricky one. As we currently determine how we handle database connections / transactions, then this doesn't classify as a bug.
[21:04] <mdiggory> We are planning to have Ben and Art Lowel be available in the upcoming week to present the details of this Simple theme to the community
[21:05] <grahamtriggs> but it is a good example of why I have kept saying that our approach to database connections / transactions doesn't scale well.
[21:05] <tdonohue> grahamtriggs -- can you work with dilberston on DS-677 then? or add your thoughts as to an alternative as necessary?
[21:06] <mdiggory> It will contain a number of enhancements to improve the ease of initially branding XMLUI that we have learned over the last couple years.
[21:06] <dilbertson> thanks graham - I'd imagined there might be a better way to handle it
[21:07] <HardyPottinger> word from our DBA is: "I would recommend nothing less than 10g, and preferably 11g. 9i support will soon be deprecated, and if they can support 11 it would be best to do that as the lifespan will be the longest"
[21:07] <grahamtriggs> tdonohue: I can keep banging my drum. But if nobody wants to dance :)
[21:07] <mdiggory> It will also enable the ability to immediately start harnessing jquery in the UI
[21:07] <mhwood> HardyPottinger: thanks, I will work that in.
[21:07] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[21:08] <PeterDietz> I think jQuery is the first thing I add to a new theme, I would recommend that to be in the default, perhaps dspace-ui-static
[21:09] <grahamtriggs> dilbertson: I don't think there is a better way of handling it in the short term. We're very constrained by the assumption that we will get a db connection and transaction at the start of a request, and keep it through to the end of the request
[21:10] <mdiggory> I thin we would agree with its need, however, even though I agreed to let it in, I'm not a fan of dspace-ui-static
[21:10] <tdonohue> mdiggory: sounds interesting. were there updates on discovery & async too?
[21:10] <grahamtriggs> ideally, we would keep transaction windows to the shortest period they can be, [probably] do most of our read queries outside of transactions, and return db connections to the pool whenever they aren't being used
[21:10] <robint> stuartlewis: Still there ? Do you have a moment for a wee Sword question ?
[21:10] <mdiggory> sorry, I know there are two conversations ongoing here.
[21:10] <stuartlewis> robint: Hi!
[21:11] <mdiggory> now three
[21:11] <stuartlewis> robint: Let's transfer ours to #dspace?
[21:11] <robint> stuartlewis: c u there
[21:11] * tdonohue if some folks need to head out, feel free. I want to continue here though, as we are under deadline soon for 1.7, and we need the updates from everyone :)
[21:11] <tdonohue> go ahead, mdiggory
[21:15] <tdonohue> mdiggory, you still here? :)
[21:15] <mdiggory> The Async research into the build process is evolving. I've reached a point where I've determined there may be two possible solutions to Asyn release. They still need proper documentation however so people can be informed for discussion, this is another area that Ben and I are still preparing
[21:15] <mdiggory> sorry, long winded
[21:15] <mhwood> Sorry, must go, will catch up later.
[21:16] * HardyPottinger has a question when the discussion settles
[21:16] * sandsfish (~sandsfish@18.111.26.116) Quit (Quit: sandsfish)
[21:16] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has left #duraspace
[21:16] <mdiggory> The first approach is as we talked about using Maven Archetypes (not actually async release but a mechanism to add modules to dspace)
[21:16] <richardrodgers> I've got to run also. Thanks all
[21:16] <grahamtriggs> HardyPottinger: is that the IRC equivalent of putting your hand up and hoping to get the teacher's attention?
[21:17] * richardrodgers (~richardro@pool-96-237-109-32.bstnma.fios.verizon.net) Quit (Quit: richardrodgers)
[21:17] <mdiggory> The second approach would be more described as "Coordinated Release"
[21:17] <HardyPottinger> grahamtriggs: lol, it might be :-)
[21:18] <mdiggory> The second approach would use a separate maven pom that checked out the dspace core + any additional modules that were required and released them all to their appropriate svn locations.
[21:19] <tdonohue> docs definitely might help everyone (or examples on wiki) -- not sure I fully understand #2 right now, but I get the basics of it
[21:20] <HardyPottinger> going with the shout it out approach: I'm working on adding a Cocoon control panel for the XMLUI admin interface, probably won't be ready in 9 days (eek) but it is working enough that I'd like to see if it's capable of clearing the Cocoon cache. Only problem? I can't seem to generate any cache...
[21:22] <HardyPottinger> I can see our live DSpace has about 1.2GB in its cache, but our dev DSpace is at 0 bytes, no matter what I click on... I'm looking for advice on tactics to generate some cache
[21:24] <tdonohue> mdiggory -- is there any other updates on discovery? or was that it for @mire updates? (Just want to see if you were done or not)
[21:25] <tdonohue> HardyPottinger -- good question. hmmm...
[21:27] <mdiggory> I think that we are overtime, so I will hold back, we still have an intention of introduce discovery with the 1.7 release, we need to still determine how tightly packaged it will be with the DSpace distribution however, getting feedback from the developer community on how important being able to turn it on easily in 1.7 with a few configuration changes is.
[21:30] <tdonohue> mdiggory -- Obviously after Oct 22, we are under feature freeze and move into testing/bug-fix mode (and preparation for testathon). So, we will need to make a decision on whether Discovery is part of testathon, or if it's an external add-on for 1.7. I'll look forward to the discussion, presumably on dspace-devel
[21:32] <mdiggory> this is why the details of async releasing need to be worked out before then. until we can maintain distribution code in the modules directory, it would be necessary to move all code going into dspace distributions into the trunk, which defeats the ability to do the type of releasing on discovery that is currently needed by the community that uses it.
[21:36] <tdonohue> hmmm... I hate to say it, but are we going to be able to work out async *before* Oct 22? It could happen, though I think we'd need to get on it (i.e. deep in discussion) as soon as possible.
[21:37] <mdiggory> I think that we need to have it or we are going to be fighting over how code gets from modules into dspace distributions.
[21:38] <tdonohue> ok -- well, then I'd suggest posting your options to dspace-devel and/or wiki as soon as possible, so we can try to bring it forward very quickly
[21:38] <mdiggory> I think that it can be worked out and I am continuing an agenda to make it clearer
[21:39] <mdiggory> The options we currently have to resolve things by the 2nd are
[21:40] <mdiggory> (1) Place the discovery code under trunk
[21:40] <mdiggory> (2) keep the discovery code where it is and adjust our build process to support releasing modules in concert with tunk
[21:41] <mdiggory> 2nd = 22nd
[21:42] <tdonohue> yea...and there's (3) leave Discovery code out of 1.7 for now (unfortunately) and aim it for 1.8 (not saying that's an ideal option -- obviously better to see if we can do #1 or #2 in time)
[21:46] * robint (5229fd08@gateway/web/freenode/ip.82.41.253.8) Quit (Quit: Page closed)
[21:50] <HardyPottinger> sent my Q to dspace-tech, gotta run, look forward to hearing more about Discovery in 1.7 on the list
[21:51] <dilbertson> goodnight
[21:51] * dilbertson (~keith-noa@lib-kgilbertson.library.gatech.edu) has left #duraspace
[21:51] * HardyPottinger (80ce8627@gateway/web/freenode/ip.128.206.134.39) Quit (Quit: Page closed)
[22:14] * tdonohue (~tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has left #duraspace
[22:35] * ThomasAJohnson (~tom@216.160.210.151) has joined #duraspace
[23:14] * mdiggory (~mdiggory@ip72-199-217-116.sd.sd.cox.net) Quit (Quit: mdiggory)
[23:24] * ThomasAJohnson (~tom@216.160.210.151) Quit (Ping timeout: 276 seconds)
[23:41] * alxp (~aoneill@99-105-58-164.lightspeed.sntcca.sbcglobal.net) Quit (Quit: alxp)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.