Timestamps are in GMT/BST.
[0:50] * stuartlewis (~stuartlew@s-lewis.itss.auckland.ac.nz) Quit (Quit: stuartlewis)
[6:29] -card.freenode.net- *** Looking up your hostname...
[6:29] -card.freenode.net- *** Checking Ident
[6:29] -card.freenode.net- *** Found your hostname
[6:29] -card.freenode.net- *** No Ident response
[6:29] [frigg VERSION]
[6:30] * DuraLogBot (~PircBot@duraspace.org) has joined #duraspace
[6:30] * Topic is 'Welcome to DuraSpace - This channel is logged - http://duraspace.org/irclogs/'
[6:30] * Set by cwilper on Tue Jun 30 20:32:05 UTC 2009
[11:35] * alxp (~alxp@PC044.ROBLIB.UPEI.CA) has joined #duraspace
[11:58] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has joined #duraspace
[12:47] * krnl_ (Andrius@193.219.34.106) Quit ()
[12:51] * krnl_ (Andrius@193.219.34.106) has joined #duraspace
[12:55] * tdonohue (~tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has joined #duraspace
[13:32] * ksclarke (~kevin@adsl-235-49-191.clt.bellsouth.net) has joined #duraspace
[14:01] * tdonohue (~tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has left #duraspace
[14:03] * tdonohue (~tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has joined #duraspace
[14:10] * scottatm (~scottatm@adhcp136.evans.tamu.edu) has joined #duraspace
[19:44] * keithgilbertson (~keith-noa@lib-kgilbertson.library.gatech.edu) has joined #duraspace
[20:00] <tdonohue> Hi all -- DSpace Developers Meeting is beginning here. Today's agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2010-08-25
[20:00] * richardrodgers (~richardro@dhcp-18-111-26-9.dyn.mit.edu) has joined #duraspace
[20:01] <tdonohue> We'll start off with a JIRA review (to continue to play catchup) -- http://jira.dspace.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=10020&resolution=-1&created%3Aprevious=-18w&assigneeSelect=&sorter/field=created&sorter/order=ASC
[20:01] <tdonohue> Today, we're starting with DS-564
[20:01] <tdonohue> Advanced Search doesnt treat ':' properly : http://jira.dspace.org/jira/browse/DS-564
[20:01] * joseblanco (8dd32b9d@gateway/web/freenode/ip.141.211.43.157) has joined #duraspace
[20:03] * PeterDietz (~PeterDiet@ACK5859s3.lib.ohio-state.edu) has joined #duraspace
[20:03] <tdonohue> Any thoughts on DS-564 -- has anyone tried this or found to be a problem locally? http://jira.dspace.org/jira/browse/DS-564
[20:03] <mhwood> Sounds like this needs more investigation to determine just what needs escaping.
[20:03] <richardrodgers> or indeed whether one solution fits all
[20:04] <tdonohue> Personally, I also wonder whether we should be allowing for Lucene searches in our searchbox -- what if someone really does want to search on ":" (and doesn't realize lucene is underneath)
[20:05] <tdonohue> Any volunteers to investigate DS-564 further? Do we just leave open & unscheduled?
[20:05] <snail> tdonohue: have you ever heard of a user actaully doing that?
[20:06] <tdonohue> snail: actually doing what? searching on a ":"? Yea, if there's a ":" in a title they might actually copy & paste the full title into the searchbox
[20:06] <snail> tdonohue: point taken
[20:06] <tdonohue> ok -- moving on, will leave DS-564 open
[20:07] <mhwood> So the question is: should we try to let Lucene expressions through, or just escape it all.
[20:07] <mhwood> OK, moving on.
[20:07] <tdonohue> mhwood -- yea, that's the question -- did you have final comments?
[20:07] * sandsfish (~sandsfish@dhcp-18-111-12-101.dyn.mit.edu) has joined #duraspace
[20:07] <mhwood> No, just trying to make sure we are all considering the same problem.
[20:07] <tdonohue> Ok, next one: DS-569: Trailing white spaces lead to wrong order of texts in browse -- http://jira.dspace.org/jira/browse/DS-569
[20:08] * keithgilbertson (~keith-noa@lib-kgilbertson.library.gatech.edu) Quit (Ping timeout: 272 seconds)
[20:08] <tdonohue> DS-569 seems logical and very minor fix -- should we ask Claudia to commit it?
[20:09] * bollini (~chatzilla@host134-12-dynamic.59-82-r.retail.telecomitalia.it) has joined #duraspace
[20:10] <PeterDietz> It looks safe to do. I'm +1
[20:10] <mhwood> Agreed, sounds simple and there is a patch. +1
[20:11] <tdonohue> +1 myself
[20:11] <tdonohue> DS-569 -- Ask claudia to commit it for 1.7 (+3 votes)
[20:11] <tdonohue> DS-570: Redirect users to current page on login http://jira.dspace.org/jira/browse/DS-570
[20:12] <PeterDietz> Oh, login and get home page is so annoying to me
[20:12] <tdonohue> yea, I know this has been an issue for a while -- we really just need a volunteer to try and figure out a way that works
[20:13] <tdonohue> (or two volunteers -- one for XMLUI and one for JSPUI)
[20:13] <mhwood> I agree, this sounds quite desirable, and someone says there is a patch.
[20:13] <PeterDietz> This could be a bit of work, I've done some work to get it going in JSPUI, so I can grab it for JSPUI atleast
[20:13] <PeterDietz> however, there are API changes involved
[20:14] <PeterDietz> So, I can take this, and ask for help where needed
[20:14] <tdonohue> that's fine, this is a major release -- API changes are allowed, assuming they are "approved" (we'd likely need to have at least another committer review the patch)
[20:14] <tdonohue> sounds good, assign DS-570 to PeterDietz
[20:14] <tdonohue> (we can find someone to help with XMLUI side as needed)
[20:15] <tdonohue> DS-575: On item pages, collection link should go to title browse, not collection splash page http://jira.dspace.org/jira/browse/DS-575
[20:16] * keithgilbertson (~keith-noa@lib-kgilbertson.library.gatech.edu) has joined #duraspace
[20:16] <sandsfish> there are also situations where, for instance, someone is sent to a login page based on requesting a restricted bitstream, at which point they need to be directed to a landing page and download the file, or the situation where shib auth redirects the user to other urls and comes back. not the simplest thing to fix comprehensively. just sayin'.
[20:16] <sandsfish> (for 570, that is.)
[20:16] <tdonohue> yep -- we can note for DS-570...thanks sandsfish
[20:17] <bollini> DS-575 -1, it is not a bug and not a general acceptable improvement
[20:17] <tdonohue> thoughts on DS-575? Needs more discussion or examples?
[20:18] <tdonohue> I'd agree, not sure this would be generally acceptable -- needs more feeback
[20:18] <tdonohue> I could suggest this be discussed by Global Outreach Committee, and see what they think
[20:19] <mhwood> Yeah, we need more end-user input on what is expected.
[20:19] <sandsfish> This is a common UX problem in MIT's instance. People are confused with this on a regular basis.
[20:19] <tdonohue> DS-575 -- forward to Global Outreach Committee? Is this really a change that would be generally acceptable?
[20:19] <PeterDietz> the improvement would need to be in what also to show on collection page. Such as recent-items, most-downloaded-items, discovery-matching-items
[20:20] <PeterDietz> ...just forwarding to browse-by-title would for one, not allow admin to edit the collection page
[20:20] <tdonohue> PeterDietz -- good point, maybe the Collection page actually needs the change
[20:21] <tdonohue> we'll move on for now, we'll wait for more feedback on DS-575
[20:21] <tdonohue> DS-585: The Content Disposition configuration is ignored by unpublished items http://jira.dspace.org/jira/browse/DS-585
[20:22] <richardrodgers> bollini: do you have a fix/patch?
[20:22] <tdonohue> bollini -- do you have a patch to fix DS-585, or you just found this bug?
[20:22] <tdonohue> (richardrodgers and i think alike)
[20:22] <bollini> oh yes I have
[20:22] <richardrodgers> then +1
[20:22] <bollini> just forget to share / commit
[20:23] <tdonohue> +1 -- can I assign it to you bollini?
[20:23] <bollini> yes
[20:23] <mhwood> +1 with patch
[20:23] <tdonohue> DS-585 -- assign to bollini, he will share patch & add to 1.7
[20:23] <tdonohue> DS-586 LDAP users with no mail field can't autoregister http://jira.dspace.org/jira/browse/DS-586
[20:25] <tdonohue> DS-586 seems like a bigger patch than I would expect -- anyone use LDAP locally, and have time to review this in more detail?
[20:25] <richardrodgers> Is there an LDAP-enabled dev who can review this?
[20:27] <tdonohue> sounds like no takers? I don't have LDAP, unfortunately
[20:28] <tdonohue> DS-586 -- Needs a volunteer who has access to LDAP
[20:28] <tdonohue> We'll do one last one
[20:28] <tdonohue> DS-587: add the capability to indicate a withdraw reason to an item ( tombstone ) -- http://jira.dspace.org/jira/browse/DS-587
[20:29] <tdonohue> DS-587 -- looks like Claudia expressed some concerns about the provided patch
[20:29] <PeterDietz> What currently happens when an item is withdrawn
[20:30] <mhwood> Sounds desirable but needs some elaboration.
[20:30] <tdonohue> PeterDietz -- currently, it just disappears -- "Page not found" 404 error
[20:31] <bollini> mmm... it is showed a thumbnail page (and the 404 code is supplied)
[20:31] <richardrodgers> I'm puzzled - I could swear tombstones used to work (not 404s)
[20:31] <mhwood> Me too.
[20:31] <tdonohue> hmmm...maybe I'm mistaken? I think it's a 404 in XMLUI at least
[20:32] <richardrodgers> Maybe it got lost in Manakin translation?
[20:32] <richardrodgers> Can we try in dspace.org demo (jsp)?
[20:32] <tdonohue> Here you go...withdrawn item
[20:33] <tdonohue> XMLUI: http://demo.dspace.org/xmlui/handle/1842/187
[20:33] <tdonohue> JSPUI: http://demo.dspace.org/jspui/handle/1842/187
[20:33] <tdonohue> JSPUI does have a tombstone
[20:33] <richardrodgers> Right no 404
[20:33] <tdonohue> XMLUI says it's "restricted"
[20:33] <tdonohue> I was wrong on both counts :)
[20:34] <tdonohue> So, it looks like DS-587 is about being able to add a reason *why* something was withdrawn (i.e. an improved tombstone msg)
[20:35] <mhwood> Wasn't there another issue about being asked to login to see that an item is withdrawn?
[20:35] <mhwood> Improved tombstone page sounds good, if we are to have one at all.
[20:36] <tdonohue> Yep -- DS-135: http://jira.dspace.org/jira/browse/DS-135 (Withdrawn items displayed as "restricted" rather than withdrawn)
[20:36] <joseblanco> the patch will show the item display page with a message by the bitstream and right about the bitstream the reason for withdraw
[20:36] <bollini> some institutions can not like the idea to show the metadata at all
[20:37] <tdonohue> joseblanco -- so, the patch actually displays all the item's metadata?, despite it being withdrawn?
[20:37] <richardrodgers> Yes, the tombstone hid the metadata also
[20:37] <joseblanco> yes. I'm trying to find one here, but have not found one yet.
[20:38] <mhwood> This may want to be configurable: either a noncommittal 404 page or a tombstone page with a reason. I feel that XMLUI is wrong either way here.
[20:38] <tdonohue> ok -- this may need more work then -- I'm not sure we should be switching functionality such that metadata is now displayed for withdrawn items -- part of the reason for withdrawal is also to get them out of Google (and other search engines), and leaving the metadata there encourages Google to still link to it
[20:38] <joseblanco> I just found one: http://deepblue.lib.umich.edu/handle/2027.42/48750
[20:39] <tdonohue> mhwood : I agree about XMLUI being "wrong" --- JSPUI is "more right" (if that makes sense)
[20:40] <tdonohue> So, for DS-587, sounds like we need an improved patch (based on Claudia's comments, and based on the metadata being displayed by default)
[20:41] <joseblanco> I am planning on cleaning it up a bit based on Claudia's comments, probably in a couple of days. If that helps.
[20:41] <mhwood> So, DS-135 will take care of XMLUI. DS-587 can be just for JSPUI.
[20:41] <bollini> mmm... I don't like the idea to show metadata for withdrawn item at all
[20:42] <tdonohue> joseblanco -- that would help. we'd need a new patch to review.
[20:42] <bollini> if you need to use withdrawn functionality to hide files just remove policies on the bitstreams
[20:43] <tdonohue> bollini -- yea, I agree with you. I think you misunderstood -- I agree that metadata should be hidden by default (perhaps there could be an option to enable display of metadata, but it needs to be off by default)
[20:43] <bollini> tdonohue - we should be care about providing a such option
[20:43] <PeterDietz> I wonder if it should throw http 403 -- forbidden
[20:44] <mhwood> Yes, I thought the reason for a tombstone was to indicate, "no, you're not crazy; we did have that, but we took it down."
[20:44] <tdonohue> PeterDietz -- probably should throw a 403, i'd agree
[20:44] <kshepherd> how permanent are withdrawals for most people?
[20:44] <joseblanco> In our case we wanted to give users a reason for the reason coming down.
[20:44] <kshepherd> just as an aside, if you want google to de-index it, i think a 410 (Gone) is best
[20:45] <mhwood> Shouldn't be 200, at any rate.
[20:45] <kshepherd> but 410 might be too strong if the item could be reinstated within a short period of time
[20:45] <tdonohue> yea the 410 description says to use 404 if not permanent: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
[20:46] <kshepherd> yep true
[20:46] <tdonohue> So, it's probably either 403 or 404 -- but definitely not 200
[20:46] <tdonohue> Ok -- we'll leave it at that -- we are running long already :)
[20:46] <mhwood> I think 403 ought to mean you need to login, or login as someone else.
[20:47] * sandsfish_ (~sandsfish@dhcp-18-111-12-101.dyn.mit.edu) has joined #duraspace
[20:47] <tdonohue> mhwood -- yea, I think 404 may be "best" for a tombstone, and 403 is "best" for a restricted item
[20:47] <tdonohue> Switching gears now -- DSpace 1.7 updates -- any to report?
[20:47] <kshepherd> tdonohue: +1
[20:47] <kshepherd> and 410 for 'purged/deleted' tombstones if we ever do those ;)
[20:48] <PeterDietz> If people could look through a jira filter:: Jira: 1.7 issues that are unresolved and no-one assigned to them. http://jira.dspace.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=10020&fixfor=10031&status=1&status=3&status=4&status=10000&assigneeSelect=unassigned&sorter/field=created&sorter/order=ASC
[20:48] <tdonohue> One other DSpace 1.7 update I know of -- the DSpace Docs to the Wiki process should be completed this weekend or early next week. (Jeff is working hard on that)
[20:49] <mhwood> This is under way? I missed that. Good thing I didn't do any doc updates lately.
[20:50] <tdonohue> mhwood -- yea, it's under way now. I mentioned it briefly last week (I thought, though maybe I forgot). In any case, avoid any docbook updates for now
[20:50] * sandsfish (~sandsfish@dhcp-18-111-12-101.dyn.mit.edu) Quit (Ping timeout: 276 seconds)
[20:50] <PeterDietz> I don't think I have anything to report
[20:50] * sandsfish (~sandsfish@dhcp-18-111-12-101.dyn.mit.edu) has joined #duraspace
[20:51] <bollini> I have some news about discovery and jspui
[20:51] <richardrodgers> I should (tdonohue twisting my arm ) put a 'curation' branch up soon so people can begin to look at it
[20:51] <tdonohue> Please help out Peter & everyone else by claiming some unresolved issues if you have a chance!
[20:51] * sandsfish_ (~sandsfish@dhcp-18-111-12-101.dyn.mit.edu) Quit (Ping timeout: 255 seconds)
[20:51] * tdonohue will stop twisting richards arm now :)
[20:51] <bollini> should we talk about it (discovery) or is better wait for Mark and discuss this on the mailing list?
[20:51] <tdonohue> bollini -- what did you want to report about discovery & JSPUI?
[20:52] <mhwood> I need to put a recurring task on my calendar to go stare at JIRA and see what I can do.
[20:52] <kshepherd> i'm going to try submit a small 'virtual sets' feature soon (focussing on oai rather than collections as a whole)
[20:52] <tdonohue> kshepherd -- OAI sets?
[20:52] <kshepherd> bollini: i'm keen to hear news :)
[20:52] <richardrodgers> kshepherd: cool do tell
[20:52] <kshepherd> tdonohue: yes.. this seems to be what most people wanted from 'virtual collections' in the first place
[20:52] <bollini> my progress are... before to have read the last mail from Mark I was at most finished the work
[20:53] <bollini> I have done a BrowseSolrDAO
[20:53] <kshepherd> richardrodgers: assigning OAI set identifiers to browse indexes, or search query results, etc..
[20:54] <richardrodgers> kshepherd: are these IDs persisted?
[20:54] <tdonohue> kshepherd -- yes, makes sense -- I'll look forward to see what you have on the OAI sets, and how it may/may not relate to that JIRA issue -- e.g. http://jira.dspace.org/jira/browse/DS-277 ,
[20:54] <kshepherd> richardrodgers: well.. that's the tricky part.. which is why i wanted to avoid the entire "collection" being virtual since that brings handles into the mix
[20:55] <kshepherd> bollini: sounds great.. anything in svn or jira?
[20:56] <bollini> ksheperd: not at the moment... I need to figure which is the best way to share
[20:57] <bollini> with the BrowseSolrDAO we get the same identical functionality of the actual system
[20:57] <bollini> but we only rely on the "search" Solr core
[20:57] <bollini> there are some issues...
[20:57] <tdonohue> bollini -- Discovery does have it's own JIRA area (http://jira.dspace.org/jira/browse/DSCR), that might be a way to share. Or you could always create an area in the SVN 'sandbox' if the patch would be way too big: http://scm.dspace.org/svn/repo/sandbox/
[20:58] <bollini> tdonohue - sandbox look good, I can start with a branch of discovery
[20:59] <tdonohue> sounds great, bollini.
[20:59] <bollini> the main issues are:
[20:59] <bollini> 1) the dspace metadata now are more rich than in the past... we have a value and an authority key
[21:00] * stuartlewis (~stuartlew@s-lewis.itss.auckland.ac.nz) has joined #duraspace
[21:00] <bollini> so we need to find a way to store both coupled data in solr
[21:00] * sandsfish_ (~sandsfish@dhcp-18-111-12-101.dyn.mit.edu) has joined #duraspace
[21:00] <bollini> my solution is store with a fixed syntax value|||authority_key
[21:01] <mhwood> There is a wiki page https://wiki.duraspace.org/display/DSPACE/DSpace+Discovery where design issues can be documented.
[21:02] <bollini> mhwood - you are right... I will put my notes here
[21:02] <tdonohue> What we did *not* get to today is any further discussion of Async Release Processes (but, mdiggory, who suggested it isn't here anyways). I'd like to discuss this next week and come up with some ideas/plans -- Please read the details in today's agenda for mdiggory's general idea: https://wiki.duraspace.org/display/DSPACE/DevMtg+2010-08-25 (Other thoughts/ideas are welcome and encouraged)
[21:03] <tdonohue> Mark's general idea is to use Maven's abilities to try and find ways to install "external addons" to Dspace (where an "addon" is a Maven project)
[21:03] * sandsfish (~sandsfish@dhcp-18-111-12-101.dyn.mit.edu) Quit (Ping timeout: 276 seconds)
[21:03] * sandsfish_ is now known as sandsfish
[21:04] <tdonohue> The two key things are Maven Archetypes (essentially templates, which can create templated files/directories), and Maven Plugins (which add custom Java-based functionality to Maven).
[21:05] <mhwood> The difficulty is how to get stuff like configuration extensions, additional page content, and the like to plugin to DSpace.
[21:05] <tdonohue> Just wanted to make you all more aware of Mark's ideas -- I'm still digging deeper into this as well. I'd appreciate your thoughts/ideas as you do the same.
[21:05] <kshepherd> mhwood: indeed..
[21:05] <tdonohue> mhwood -- yea, I don't think Maven will help with that. I think that's more of a "plugin framework"
[21:06] <bollini> just my fast 2cents... async release often requires complex compatibility matrix
[21:06] <kshepherd> i was wondering the other day whether a 'conf.d'-style directory in [dspace] would be better than a single dspace.cfg
[21:06] <mhwood> If we can make space for such actions, Maven can capitalize on them.
[21:06] * joseblanco (8dd32b9d@gateway/web/freenode/ip.141.211.43.157) Quit (Quit: Page closed)
[21:06] <kshepherd> so new configs for particular modules/plugins/features can be added and removed rather than merged into one file
[21:07] <tdonohue> kshepherd -- interesting idea, and simple enough :)
[21:07] <kshepherd> and everything in that dir gets parsed by ConfigurationManager
[21:07] <richardrodgers> kshepherd: in my curation stuff, I just add a config subdirectory - drop it in and it is accessable
[21:07] <sandsfish> I also wonder about UNinstalling, were something to go wrong. Or would a user have to go picking out the thorns... food for thought.
[21:07] <bollini> configuration options can be already splitted
[21:07] <mhwood> Yes. There is another current, though: moving all but essential bootstrap configuration data into the database. How to modularize that...?
[21:07] <bollini> take a look at the dspace-service framework
[21:08] <bollini> options for the dspace-services and dspace-discovery are retrieved from external files (not dspace.cfg)
[21:08] <kshepherd> richardrodgers: not sure if i follow.. unless we're talking about the same thing in slightly different ways ;)
[21:09] <tdonohue> yea -- once you build more into the dspace-services framework, that idea does come along with it. But, currently, most of our code still uses the old ConfigurationManager :(
[21:09] <kshepherd> yeah sorry i was just going on a config tangent
[21:09] <richardrodgers> kshepherd: I extended ConfigurationManager to look for arbitrary files in config
[21:09] <kshepherd> richardrodgers: right.. yep, that's pretty much what i was thinking
[21:09] <richardrodgers> it's trivial and easy
[21:09] <mhwood> First step in moving to services-style configuration is a ConfigurationManager that wraps it.
[21:10] <tdonohue> mhwood -- yea, we need a volunteer to help make that happen :)
[21:11] * tdonohue notes we're well over time...head out if you need to. We'll dig more into Async next week (and perhaps more config talk too if needed) -- other topic ideas welcome, pass them along
[21:12] <mhwood> Ah, yes, must go. Thanks, all!
[21:12] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has left #duraspace
[21:13] <sandsfish> bye all
[21:13] * sandsfish (~sandsfish@dhcp-18-111-12-101.dyn.mit.edu) Quit (Quit: sandsfish)
[21:13] <bollini> I go too, see you next week
[21:13] <richardrodgers> Also must go - thanks all
[21:14] <kshepherd> cheers all
[21:14] * richardrodgers (~richardro@dhcp-18-111-26-9.dyn.mit.edu) Quit (Quit: richardrodgers)
[21:14] * bollini (~chatzilla@host134-12-dynamic.59-82-r.retail.telecomitalia.it) Quit (Quit: ChatZilla 0.9.86 [Firefox 3.6.8/20100722155716])
[21:15] * keithgilbertson (~keith-noa@lib-kgilbertson.library.gatech.edu) Quit (Quit: keithgilbertson)
[21:39] * alxp (~alxp@PC044.ROBLIB.UPEI.CA) Quit (Quit: alxp)
[22:11] * tdonohue (~tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has left #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.