Timestamps are in GMT/BST.
[6:33] -card.freenode.net- *** Looking up your hostname...
[6:33] -card.freenode.net- *** Checking Ident
[6:33] -card.freenode.net- *** Found your hostname
[6:33] -card.freenode.net- *** No Ident response
[6:33] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:33] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:33] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[13:30] * tdonohue (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) has joined #duraspace
[14:07] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has joined #duraspace
[15:22] * robint_ (81d7a972@gateway/web/freenode/ip.129.215.169.114) has joined #duraspace
[15:22] * robint_ (81d7a972@gateway/web/freenode/ip.129.215.169.114) Quit (Client Quit)
[18:02] * grahamtriggs (~Graham@cpc2-stev6-2-0-cust333.9-2.cable.virginmedia.com) has joined #duraspace
[18:25] * sandsfish (~sandsfish@c-24-60-203-182.hsd1.ma.comcast.net) has joined #duraspace
[18:32] * sandsfish (~sandsfish@c-24-60-203-182.hsd1.ma.comcast.net) has left #duraspace
[18:33] * sandsfish (~sandsfish@c-24-60-203-182.hsd1.ma.comcast.net) has joined #duraspace
[18:33] * sandsfish (~sandsfish@c-24-60-203-182.hsd1.ma.comcast.net) has left #duraspace
[18:33] * sandsfish (~sandsfish@c-24-60-203-182.hsd1.ma.comcast.net) has joined #duraspace
[18:55] * vhollister (48c88f7e@gateway/web/freenode/ip.72.200.143.126) has joined #duraspace
[19:50] <tdonohue> Reminder: we'll be having our weekly DSpace Developers Mtg here in about 10 mins. Agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-04-13
[19:50] <kompewter> [ DevMtg 2011-04-13 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-04-13
[19:54] * robint (52292151@gateway/web/freenode/ip.82.41.33.81) has joined #duraspace
[19:55] * KevinVdV (~KevinVdV@d54C15567.access.telenet.be) has joined #duraspace
[19:59] * aschweer (~schweer@schweer.its.waikato.ac.nz) has joined #duraspace
[19:59] * h_pottinger (a182f583@gateway/web/freenode/ip.161.130.245.131) has joined #duraspace
[20:00] <tdonohue> Hello, all. It's time for our DSpace Developers Mtg. Agenda at: https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-04-13
[20:00] <kompewter> [ DevMtg 2011-04-13 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-04-13
[20:01] <tdonohue> As usual, we'll start off with JIRA Reviews. Again, try to keep to just a few minutes per issue. Here's our list of issues needing review: https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+resolution+%3D+Unresolved+AND+Key%3E%3DDS-770+ORDER+BY+key+ASC
[20:01] <kompewter> [ https://jira.duraspace.org/browse/DS-770 ] - [#DS-770] New Japanese messages for 1.7.0 - DuraSpace JIRA
[20:01] <kompewter> [ Issue Navigator - DuraSpace JIRA ] - https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+resolution+%3D+Unresolved+AND+Key%3E%3DDS-770+ORDER+BY+key+ASC
[20:01] <tdonohue> First up is DS-770
[20:01] <kompewter> [ https://jira.duraspace.org/browse/DS-770 ] - [#DS-770] New Japanese messages for 1.7.0 - DuraSpace JIRA
[20:02] * PeterDietz (~PeterDiet@sul272peter.lib.ohio-state.edu) has joined #duraspace
[20:02] <sandsfish> anyone speak japanese?
[20:02] <tdonohue> oh...looks like Claudia has already started this one. may want to just follow up with her to see if she needs help on Ds-770
[20:02] <tdonohue> we usually accept these translations as-is...Claudia tends to lead the translation work :)
[20:03] <tdonohue> Summary Ds-770: Ask Claudia for updates. Does she need additional help/support?
[20:03] <tdonohue> skipping ahead to... DS-771
[20:03] <kompewter> [ https://jira.duraspace.org/browse/DS-771 ] - [#DS-771] Installed version of DSpace display - DuraSpace JIRA
[20:04] <sandsfish> question answered?
[20:04] <tdonohue> +1 to also adding DSpace version to XMLUI Control Panel. Seems like a useful (and relatively simple) change to me.
[20:04] <mhwood> Won't fix; use the META?
[20:05] <tdonohue> I like the suggestion of adding it to XMLUI control panel, myself...for non-techies
[20:05] <sandsfish> sounds reasonable and easy.
[20:05] <tdonohue> (it may also help with bug/issue reports -- "Please look up your DSpace version in your Admin control panel")
[20:05] <mhwood> Yeah, this question comes up from time to time.
[20:05] <PeterDietz> I noticed that OJS will show you all the versions that you've used at one time. i.e. 2.2.2 installed 2009/10/12, 2.3.3 installed 2011/03/05
[20:06] <tdonohue> any volunteers to tackle? seems like a relatively small change?
[20:06] <PeterDietz> I'll take it, for fun
[20:06] <tdonohue> ok. Summary Ds-771: Assign to PeterDietz. Look into displaying version in XMLUI Control Panel
[20:07] <tdonohue> Next: DS-775
[20:07] <kompewter> [ https://jira.duraspace.org/browse/DS-775 ] - [#DS-775] Implementation of DayTableEmbargoSetter.java not working as expected. - DuraSpace JIRA
[20:08] <mhwood> Has anyone else seen it do this? How is it incorrect?
[20:08] <PeterDietz> I think the old one, if you had a 366 year embargo, it would be liftable after 365 days. (assummed year has 365 days as opposed to ~365.25)
[20:09] <PeterDietz> oops liftable after 365 years, not days
[20:09] <tdonohue> needs analysis? volunteer?
[20:09] <mhwood> I can look at it.
[20:09] <tdonohue> ok. Ds-775 summary: Assign mhwood. Analyze & report back
[20:09] <PeterDietz> current way is: http://scm.dspace.org/svn/repo/dspace/trunk/dspace-api/src/main/java/org/dspace/embargo/DayTableEmbargoSetter.java
[20:10] <tdonohue> Next up: DS-777
[20:10] <kompewter> [ https://jira.duraspace.org/browse/DS-777 ] - [#DS-777] PackageUtils.translateGroupNameForExport returns null unexpectedly - DuraSpace JIRA
[20:11] <mhwood> Seems to be assigned.
[20:11] <tdonohue> oh wait. I thought I resolved this? suggest leave assigned to me, and I'll look into it
[20:11] <tdonohue> Ds-777: leave assigned to tdonohue, he'll look into it
[20:11] <tdonohue> Next: DS-778
[20:11] <kompewter> [ https://jira.duraspace.org/browse/DS-778 ] - [#DS-778] DSpace Makes Improper Assumptions about Group Names for Permission/Role based Groups - DuraSpace JIRA
[20:12] <tdonohue> This was an annoying discovery of mine during the AIP work. XMLUI actually parses group names into *roles* (thus meaning XMLUI cannot let you rename groups)
[20:13] <mhwood> +1 group names shouldn't have meaning to the code. Names are for humans.
[20:13] <PeterDietz> would it make sense to add more brains to (dspace-api) Groups, as opposed to making the UI do lots of heavy lifting (possibly incorrect attempts)
[20:13] <grahamtriggs> +/- 0 :)... thing is, magic numbers really aren't any better
[20:14] <tdonohue> PeterDietz -- yea, the UI shouldn't be making assumptions on group names, etc
[20:15] <mhwood> If you want an internally-generated Group, you ask for that, and it gets a meaningless name. If you try to create a group with a name like that, you get an exception. Document that you should not name groups according to some pattern that's reserved for internal use.
[20:15] <tdonohue> grahamtriggs -- not just about the "magic numbers" in names. XMLUI also allows you to create a "COLLECTION_<ID>_DEFAULT_READ" group which is never associated to the Collection via DB, and doesn't do anything in JSPUI, etc
[20:16] <tdonohue> ok, sounds like general consensus that this needs more analysis, needs a (hopefully) better solution
[20:17] <tdonohue> Summary Ds-778: More analysis on better solution. Current hardcoded logic in XMLUI probably not the best way to do this. Needs volunteer.
[20:18] <tdonohue> Next: DS-780
[20:18] <kompewter> [ https://jira.duraspace.org/browse/DS-780 ] - [#DS-780] MetadataExposure.java doesn't check the boolean value of hidden field in dspace.cfg - DuraSpace JIRA
[20:19] <robint> This looks to be related to various other issues including DS-800
[20:19] <kompewter> [ https://jira.duraspace.org/browse/DS-800 ] - [#DS-800] Manage visibilty of metadata fields as field attribute rather than in dspace.cfg - DuraSpace JIRA
[20:20] <tdonohue> ok, looks like you are tackling some of this, robint? At least DS-655 which is also related?
[20:20] <kompewter> [ https://jira.duraspace.org/browse/DS-655 ] - [#DS-655] MetadataExposure hides fields except for System Admins - this should extend to Community and Collection Admins - DuraSpace JIRA
[20:21] <robint> My first reaction is that metadata fields should be DSO's with resource policies but I dont know how practical that is
[20:21] <mhwood> It's a lot of work, but work that we need to do.
[20:21] * PeterDietz sends telkinetic message to mdiggory to wake up and join
[20:21] <tdonohue> ok. So, is suggestion to wait on the smaller Ds-780 bug until we tackle larger issues?
[20:22] * tdonohue notes mdiggory is out of town/office. won't be here today
[20:22] <mhwood> Larger issues should take care of it.
[20:22] <aschweer> isn't DS-780 just a bug in how the config is parsed?
[20:22] <kompewter> [ https://jira.duraspace.org/browse/DS-780 ] - [#DS-780] MetadataExposure.java doesn't check the boolean value of hidden field in dspace.cfg - DuraSpace JIRA
[20:22] <aschweer> ie when you set hide to false, it should stop hiding it?
[20:22] <kshepherd> hrm, i thought i'd done some work on fixing MetadataExposure consistency recently
[20:23] <mhwood> Good point. The current mechanism should at least work, even if we dislike it and intend to replace it someday.
[20:23] <tdonohue> that's how I read Ds-780 as well...that it was a minor bug in how the config is parsed (like aschweer said)
[20:23] <robint> aschweer: yes but Claudia amongst others has asked for a more sophisticated mechanism
[20:23] <tdonohue> volunteer to look at Ds-780 (which seems minor) in nearterm?
[20:23] <aschweer> robint: yes I'm aware of that, but looks like that's going to take some time to figure out how and implement
[20:24] <robint> assign to me if you like
[20:24] <tdonohue> Ds-780: assign robint. See if it may be fixable before all the other larger, sophisticated changes
[20:24] <tdonohue> OK. We'll quit there for today
[20:25] <tdonohue> Next topic: GSoC 2011. Much of the details are in the agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-04-13
[20:25] <kompewter> [ DevMtg 2011-04-13 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-04-13
[20:25] <tdonohue> Essentially, we were given only 5 slots from Google this year. DuraCloud & Fedora both want 1 apiece. That leaves us with 3
[20:26] <tdonohue> Currently, we are still in the process of scoring/ranking (IF you want to mentor and haven't scored anything yet, please log in and do so!)
[20:26] <tdonohue> there are current *2* projects which are extremely highly ranked. The 3rd one is still a bit "up in the air" still
[20:27] <grahamtriggs> is that DuraCloud & Fedora position before or after scoring?
[20:27] <tdonohue> Duracloud and Fedora are ranking their projects separate from ours. I'm talking only about DSpace projects in my numbers...sorry, that may not have been clear. We have *2* highly ranked DSpace projects so far
[20:28] <tdonohue> But, DuraCloud has *1* highly ranked project, which they'd like to accept. Fedora also has *1* that they'd like to accept. that leaves us with 3 slots for DSpace
[20:29] <tdonohue> As it currently stands, the 2 DSpace projects which look likely are related to the "SKOS Authority Control" idea, and the "RTMP A/V Streaming" idea. https://wiki.duraspace.org/display/GSOC/DSpace+Summer+of+Code+Ideas
[20:29] <kompewter> [ DSpace Summer of Code Ideas - Google Summer of Code - DuraSpace Wiki ] - https://wiki.duraspace.org/display/GSOC/DSpace+Summer+of+Code+Ideas
[20:30] <tdonohue> The third DSpace slot is a little up in the air, which is why it is *important to vote* if you haven't yet :)
[20:31] <tdonohue> Any questions / comments on GSoC stuff? (Also welcome to contact me in private, if you have questions about specific project applications, etc)
[20:33] <tdonohue> Also, I should note, if we only end up with 3 projects, we may encourage co-mentorship (2-3 per project). Obviously at this point, it sounds like we have more "interested mentors" than projects slots.
[20:34] <tdonohue> (if somehow we end up really wanting 4 DSpace projects, we may be able to request another from Google... if any more become available. But, right now, not sure if that will be necessary)
[20:34] * kshepherd is getting... 'less interested'
[20:34] <tdonohue> uh-oh. kshepherd is listed as a possible lead mentor on one :)
[20:35] <kshepherd> heh
[20:36] <PeterDietz> I don't know what to say in public forum, but for the submission interface project, I would consider mentoring for intuitiveness improvements in submissions (UI/UX), not so much refactoring the database/inputforms
[20:37] <tdonohue> In any case, we are getting short on time here. So, it'd be good if we can hash this out quickly, and decide on GSoC projects soon, along with mentors. I'll send out an email to all interested mentors + committers privately, so that we can get this moving along quickly.
[20:38] <tdonohue> if you want to *specifically* volunteer to mentor one project/student (and you haven't already), please get in touch
[20:38] <tdonohue> Next Topic for today: OR11 Face to Face. We have a Room now: https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-06-06+-+OR11+Meeting
[20:38] <kompewter> [ DevMtg 2011-06-06 - OR11 Meeting - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-06-06+-+OR11+Meeting
[20:39] <mhwood> Good news indeed.
[20:40] <tdonohue> Any preference on a starting time from those planning on attending? We have the room from 8am-4pm on Monday. But, I'd be willing to push back start to 9am or possibly 10am if we felt it'd be better
[20:40] <robint> 8am! gulp.
[20:41] <mhwood> I'm one of those awful morning people.
[20:41] <PeterDietz> ...atleast I gain an hour through time-change
[20:41] <kshepherd> pssh
[20:41] <tdonohue> I was debating on pushing back to 9am to be honest. :)
[20:41] <kshepherd> these dev meetings start at 8am for us hard kiwis ;)
[20:42] <kshepherd> though it's a bit easier to be bleary-eyed on IRC, i guess
[20:42] <robint> Wouldn't want to discourage others from meeting earlier but +1 for 9am for me
[20:42] <grahamtriggs> I'll be getting in to Austin late on Sunday... happy to start any time on Monday (although haven't booked a hotel yet!). Maybe a tentative start for 9am, but we can play it by ear depending on when people actually turn up
[20:43] <tdonohue> Ok. Sounds like tentatively we'll say 9am. We can always show up earlier to chat over coffee as we wake up -- as if we won't get enough of each other that day already :)
[20:44] <grahamtriggs> offer an iPad 2 to the first person to turn up - everyone will be queueing from 2am, and we can start on time :)
[20:44] <tdonohue> Ok. moving on here. (sorry to change topics again quickly...wanted to get to this): DCAT Review of DS-587
[20:44] <kompewter> [ https://jira.duraspace.org/browse/DS-587 ] - [#DS-587] add the capability to indicate a withdraw reason to an item ( tombstone ) - DuraSpace JIRA
[20:44] * tdonohue haha... sorry, don't have an extra iPad 2 handy
[20:45] <PeterDietz> also, of note, they don't serve beer in the cafeteria in US schools, and its unlikely to be two bottles of wine per table
[20:45] <tdonohue> DCAT has done their initial review of Ds-587. They recommend implementing it, but want us to review the newly updated patch from Michigan, just posted to DS-587
[20:45] <kompewter> [ https://jira.duraspace.org/browse/DS-587 ] - [#DS-587] add the capability to indicate a withdraw reason to an item ( tombstone ) - DuraSpace JIRA
[20:46] * richardrodgers (~richardro@173-9-7-35-New-England.hfc.comcastbusiness.net) has joined #duraspace
[20:46] <kshepherd> PeterDietz: wine at 8am sounds rough even for me...
[20:46] * tdonohue sidenote to PeterDietz's joke: we will have beer *after* the meeting...planning a meetup at a local bar with Fedora Devs & whomever else is around
[20:47] <tdonohue> In any case...back to DCAT & DS-587. I know the new patch is a bit larger, so it may be difficult to do a thorough review now. But, does anyone want to volunteer to look into this more closely and give more feedback on the suggested Tombstone changes?
[20:47] <kompewter> [ https://jira.duraspace.org/browse/DS-587 ] - [#DS-587] add the capability to indicate a withdraw reason to an item ( tombstone ) - DuraSpace JIRA
[20:47] <grahamtriggs> seems massively over complicated trying to pick out information from the provenance
[20:48] <richardrodgers> I can have a look at it
[20:50] <tdonohue> Ok, richardrodgers, that'd be good. We basically are looking for feedback to give back to both DCAT & Michigan. Suggesting changes, etc.
[20:50] <vhollister> Michigan is also willing to write the XML version -- but needs some guidence
[20:50] <tdonohue> it'd probably be best to comment on Ds-587 with any feedback directly. I know DCAT is following that issue
[20:50] <richardrodgers> yep - I just noticed that for Manakin at least, Tombstones are a bit broken...
[20:51] <grahamtriggs> not to mention fragile... we've talked about an internal metadata schema - shouldn't we just hold off until we've got that schema (1.8?) and ensure that we've got appropriate field(s) that can be addressed directly. More robust, and a shed load less code.
[20:51] <PeterDietz> my admins have also expressed interest in tombstones/withdraw so I'll likely have a look too
[20:52] <tdonohue> If others have thoughts/suggestions, I'd encourage adding them to Ds-587 comments. It'd be great to see some version of this make it into 1.8 (whether it's the michigan code or something slightly different that we rework)
[20:52] <richardrodgers> yes grahamtriggs : the answer might be: we can do it properly with internal metadata....
[20:52] <tdonohue> thanks to both PeterDietz & richardrodgers!
[20:52] <vhollister> agree w/tdonohue -- good if some version made it into 1.8
[20:52] <vhollister> yes, thx!
[20:53] <tdonohue> yes, I'd also agree that might be the answer grahamtriggs. The main idea is not that we *have* to accept the patch as-is. More, that DCAT sees this as an important feature worth gettting into 1.8. How it ends up in 1.8 could be different than the current patch
[20:55] <tdonohue> Ok. we only have 5 minutes left here, so I hesitate to dig into the "time permitting" discussion I had on the agenda (around Async Releases). Not enough time today, plus it'd probably be good to ensure mdiggory is around for that one as well
[20:55] <tdonohue> Any last topics / ideas to discuss, etc?
[20:56] <robint> Does anyone know how Cocoon caching works ?
[20:56] <PeterDietz> .addpoint robint
[20:56] <kompewter> robint: +1/-0, 1
[20:56] <grahamtriggs> for our purposes... not that well :)
[20:56] <kshepherd> robint: i know how to turn it off... ;)
[20:56] <PeterDietz> kshepherd: Do tell
[20:56] <robint> kshepherd: Tell all
[20:57] <kshepherd> well, for a specific pipeline, i mean
[20:57] <tdonohue> robint: I took mdiggory's comment on that issue as saying "As none of us fully understand cocoon caching, we might want to dig into it more, or turn it off altogether"
[20:57] <tdonohue> (I admit to not fully understanding it, unfortunately)
[20:57] <grahamtriggs> is there anything about Cocoon that any of us fully understand?
[20:58] <kshepherd> re caching: take a look at the "caching" and "noncaching" pipe definitions in sitemap.xmap
[20:58] <mhwood> Heh, the last Cocoon book came out in 2003 when 2.0 was brand-new.
[20:59] <robint> Does turning off caching for one pipeline affect subsequent pipelines ?
[20:59] <tdonohue> grahamtriggs: (haha) um, yea, I understand how to configure it...but, the caching part is one area I've not dug into quite as far
[21:00] <tdonohue> robint: I *think* so (vaguely remember hearing that). But, I could be wrong there
[21:00] <kshepherd> robint: good question.. not 100% sure
[21:00] <robint> You would think so but PeterDietz testing suggests not
[21:00] <grahamtriggs> http://mail-archives.apache.org/mod_mbox/cocoon-users/201102.mbox/%3C7C655C04B6F59643A1EF66056C0E095EA99C94@eusex01.sweden.ecsoft%3E
[21:01] <kompewter> [ RE: How-to disable caching for Cocoon2.2 completely ] - http://mail-archives.apache.org/mod_mbox/cocoon-users/201102.mbox/%3C7C655C04B6F59643A1EF66056C0E095EA99C94@eusex01.sweden.ecsoft%3E
[21:02] * tdonohue notes that we are just chatting now. If others need to head out, feel free. No more "official topics" today. (that being said, I'll stick around to talk cocoon caching for a bit)
[21:02] * vhollister (48c88f7e@gateway/web/freenode/ip.72.200.143.126) Quit (Quit: Page closed)
[21:03] * KevinVdV (~KevinVdV@d54C15567.access.telenet.be) Quit (Quit: KevinVdV)
[21:03] <PeterDietz> here's some of my butcherings that still has caching https://gist.github.com/918411
[21:03] <richardrodgers> thanks all, have to run, bye
[21:03] <kompewter> [ attempting to disable cocoon cache in dspace xmlui — Gist ] - https://gist.github.com/918411
[21:03] * richardrodgers (~richardro@173-9-7-35-New-England.hfc.comcastbusiness.net) Quit (Quit: richardrodgers)
[21:04] <robint> Unfortunately got to run myself. Cheers all.
[21:04] <kshepherd> disabling caching on ViewArtifact's pipeline has not resulted in a noticeable performance decrease for me, but has helped with keeping session/state info better up to date, etc
[21:04] <tdonohue> PeterDietz, so even though you configured as 'noncaching' there still is caching?
[21:05] <PeterDietz> yep.. however, I did just notice this bit:
[21:05] <PeterDietz> <map:pipes default="caching">
[21:05] <PeterDietz> <map:pipe name="noncaching" src="org.apache.cocoon.components.pipeline.impl.NonCachingProcessingPipeline">
[21:05] <PeterDietz> </map:pipe>
[21:05] <PeterDietz> <map:pipe name="caching" src="org.apache.cocoon.components.pipeline.impl.CachingProcessingPipeline">
[21:05] <PeterDietz> </map:pipe>
[21:05] <PeterDietz> </map:pipes>
[21:05] <tdonohue> well -- maybe it could be worth investigating switching *everything* to 'noncaching', and testing performance, etc. Obviously we have a bit too *much* caching going on right now
[21:05] <kshepherd> that's where caching vs noncaching is defined
[21:05] <PeterDietz> lemme try. Cheers all, I'll keep plugging away at this.. since we've delayed our upgrade to 1.7.1 indefinitely until we resolve certain cache parts
[21:06] * robint (52292151@gateway/web/freenode/ip.82.41.33.81) Quit (Quit: Page closed)
[21:06] <mhwood> Must go. Thanks all!
[21:06] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has left #duraspace
[21:06] <kshepherd> i definitely prove that switching the (only) pipeline in ViewArtifacts aspect to noncaching definitely stops caching ;)
[21:07] <kshepherd> s/definitely/can/
[21:07] <kompewter> kshepherd meant to say: i can prove that switching the (only) pipeline in ViewArtifacts aspect to noncaching definitely stops caching ;)
[21:07] <sandsfish> headed out. bye all.
[21:07] <kshepherd> i should probably try it on more/everything, as suggested
[21:07] * sandsfish (~sandsfish@c-24-60-203-182.hsd1.ma.comcast.net) Quit (Quit: sandsfish)
[21:08] <PeterDietz> my simple test is 1.7.1 xmlui search/browse/view (disabled artifactbrowser). visit collection, submit new item to collection, look at recently submitted items and see if new item appears
[21:09] <tdonohue> well, I guess it's also a question of how much the caching is "buying us". If there are areas that actually are worth caching that's fine. It just may be easier to turn it all *off*, and then slowly turn back *on* various areas in order to attempt "harmony" :)
[21:11] <tdonohue> one idea is whether we should also just switch are settings so that *noncaching* is the default. That way we only cache pipelines which we *know* we want to cache (just an idea)
[21:11] <kshepherd> PeterDietz: ok, hvaen't tested that particular one yet
[21:11] <kshepherd> should just be a case of switching to noncaching for the discovery aspect pipeline, methinks
[21:12] <kshepherd> (and making sure solr is behaving too ;))
[21:12] <tdonohue> yea -- true. idea needs lots of testing obviously :)
[21:12] <PeterDietz> (not using discovery)
[21:13] <kshepherd> ah
[21:13] <kshepherd> sorry, bad assumption after reading 'disabled artifactbrowser'
[21:13] <PeterDietz> I'm thinking to switch on discovery atleast for this, since discovery does provide the ability to do so
[21:14] <PeterDietz> ..yeah sorry, thats only due to upgrading from 1.6 to 1.7 that we disabled it. I did feel somewhat confused about what search/view/browse provide and if i want them or not. (if I were not a developer I'd be lost)
[21:15] <kshepherd> yeah, unfortunate that RecentSubmissions never quite got separated into its own aspect in standard xmlui..? (especially since i did do that once, then stuck the patch somewhere stupid and forgot about it :P)
[21:16] <kshepherd> so, we can disable artifactbrowser to work the new way, but *recentsubmissions still comes from org.dspace.app.xmlui.artifactbrowser?
[21:17] <PeterDietz> I've also run into the problem where items marked as having a creative commons license don't have the "appears in collections" list showing its collections.. that one's somewhat mind-boggling, and not reproduceable, as its just affecting one of our servers
[21:17] <PeterDietz> yeah there is lots of stuff that is still packaged under artifact browser
[21:18] <PeterDietz> I suppose 1.7 is deprecate, and 1.8 will be to complete a shift. I don't know if there is further traction, other than what was needed to be done to get discovery to work
[21:20] <kshepherd> yeah guess the rest just needs moving to searchArtifacts by 1.8
[21:20] <kshepherd> i've been too deep in discovery to notice anything else ;)
[21:22] <PeterDietz> I'm thinking our metadata is a mess, so its rough to make sense of it, from what discovery gives us
[21:23] <PeterDietz> sorry, gotta head home. I'll keep digging away at what I can with cache/recent-submissions
[21:23] <kshepherd> i'll take a look if i have some time, too
[21:26] * PeterDietz (~PeterDiet@sul272peter.lib.ohio-state.edu) has left #duraspace
[21:27] <kshepherd> i knew there was a patch i did for MetadataExposure
[21:27] <kshepherd> tdonohue: i think DS-780 is already fixed by the patched i committed to DS-853
[21:27] <kompewter> [ https://jira.duraspace.org/browse/DS-780 ] - [#DS-780] MetadataExposure.java doesn't check the boolean value of hidden field in dspace.cfg - DuraSpace JIRA
[21:27] <kompewter> [ https://jira.duraspace.org/browse/DS-853 ] - [#DS-853] MetadataExposure settings for dc.description.provenance are ignored/overridden by XMLUI templates - DuraSpace JIRA
[21:29] <tdonohue> kshepherd: oh, ok. yea, they *look* like the same issue, at a glance. Can you double check, and if so, close DS-780 and link to DS-853? Thanks!
[21:29] <kompewter> [ https://jira.duraspace.org/browse/DS-780 ] - [#DS-780] MetadataExposure.java doesn't check the boolean value of hidden field in dspace.cfg - DuraSpace JIRA
[21:29] <kompewter> [ https://jira.duraspace.org/browse/DS-853 ] - [#DS-853] MetadataExposure settings for dc.description.provenance are ignored/overridden by XMLUI templates - DuraSpace JIRA
[21:29] <kshepherd> tdonohue: yep will check 1.6.2 today, apply same fix (it's very simple) and see if that resolves ds-780 too
[21:29] <kompewter> [ https://jira.duraspace.org/browse/ds-780 ] - [#DS-780] MetadataExposure.java doesn't check the boolean value of hidden field in dspace.cfg - DuraSpace JIRA
[21:30] <tdonohue> thanks, sounds good!
[21:31] * h_pottinger (a182f583@gateway/web/freenode/ip.161.130.245.131) has left #duraspace
[21:50] * aschweer (~schweer@schweer.its.waikato.ac.nz) has left #duraspace
[21:55] * grahamtriggs (~Graham@cpc2-stev6-2-0-cust333.9-2.cable.virginmedia.com) Quit (Quit: Leaving)
[22:07] * tdonohue (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) has left #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.