Timestamps are in GMT/BST.
[0:20] * bradmc (~bradmc@c-66-30-9-86.hsd1.ma.comcast.net) Quit (Quit: bradmc)
[4:40] * stuartlewis (~stuartlew@s-lewis.itss.auckland.ac.nz) Quit (Quit: stuartlewis)
[4:46] * stuartlewis (~stuartlew@s-lewis.itss.auckland.ac.nz) has joined #duraspace
[5:00] * ksclarke (~kevin@adsl-39-10-103.clt.bellsouth.net) Quit (Quit: Leaving.)
[6:31] -card.freenode.net- *** Looking up your hostname...
[6:31] -card.freenode.net- *** Checking Ident
[6:31] -card.freenode.net- *** Found your hostname
[6:31] -card.freenode.net- *** No Ident response
[6:31] [frigg VERSION]
[6:31] * DuraLogBot (~PircBot@duraspace.org) has joined #duraspace
[6:31] * Topic is 'Welcome to DuraSpace - This channel is logged - http://duraspace.org/irclogs/'
[6:31] * Set by cwilper on Tue Jun 30 20:32:05 UTC 2009
[11:10] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[12:08] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has joined #duraspace
[13:27] * tdonohue (~tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has joined #duraspace
[13:32] * ksclarke (~kevin@adsl-39-10-103.clt.bellsouth.net) has joined #duraspace
[13:43] * ksclarke (~kevin@adsl-39-10-103.clt.bellsouth.net) Quit (Ping timeout: 276 seconds)
[13:56] * ksclarke (~kevin@adsl-39-10-103.clt.bellsouth.net) has joined #duraspace
[14:24] * bradmc_ (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[14:24] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: Connection reset by peer)
[14:24] * bradmc_ is now known as bradmc
[16:02] * dericed (~Adium@pool-108-14-205-86.nycmny.east.verizon.net) has joined #duraspace
[16:52] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Ping timeout: 248 seconds)
[16:53] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[18:39] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Quit: bradmc)
[18:49] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[19:24] * dericed (~Adium@pool-108-14-205-86.nycmny.east.verizon.net) Quit (Quit: Leaving.)
[19:30] * bollini (~chatzilla@host223-235-dynamic.16-87-r.retail.telecomitalia.it) has joined #duraspace
[19:37] * Manuela (8f36ebd3@gateway/web/freenode/ip.143.54.235.211) has joined #duraspace
[19:42] * Manuela (8f36ebd3@gateway/web/freenode/ip.143.54.235.211) Quit (Ping timeout: 252 seconds)
[19:54] * keithgilbertson (~keithgilb@207.138.47.158) has joined #duraspace
[19:57] * PeterDietz (~PeterDiet@ACK5859s3.lib.ohio-state.edu) has joined #duraspace
[19:58] <tdonohue> Hi all. DSpace Devel Mtg here in a few minutes -- agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2010-08-18
[20:01] <tdonohue> Ok -- it's the top of the hour. May as well get started with a JIRA review. Here's a list of recent open issues -- we'll be starting with DS-553 : 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> Display date generation only works on dates without time granularity : http://jira.dspace.org/jira/browse/DS-553
[20:02] <tdonohue> oh -- it looks like kshepherd already said DS-553 is fixed? Anyone else tried this out?
[20:02] * richardrodgers (~richardro@pool-173-76-18-245.bstnma.fios.verizon.net) has joined #duraspace
[20:02] <PeterDietz> I remember kshepherd and claudia having trouble with these dcdates
[20:03] <PeterDietz> however, i can't find any more info on this issue
[20:03] <tdonohue> ok -- Assign DS-553 to kshepherd for further verification & ask him to close it if it is fixed (since it sounds like it is)
[20:04] <richardrodgers> Wasn't robinT also looking into this?
[20:04] <tdonohue> hi richardrodgers -- yea, this seems related to the DCDates problems -- but, it sounds like this one is fixed: http://jira.dspace.org/jira/browse/DS-553
[20:05] <mhwood> I think there are several issues that boil down to surprising abbreviation of the date output in various circumstances.
[20:05] <richardrodgers> Ah, ok thanks
[20:06] <tdonohue> So, in the essence of time, I'm going to assign DS-553 to kshepherd for verification & closing (unless there's any other volunteers)
[20:06] <tdonohue> Inconsistent creation of dc.date.issued : http://jira.dspace.org/jira/browse/DS-554
[20:08] <tdonohue> I'm not sure this is a bug? Should it matter if the date has time granularity or not (as long as we can handle both)?
[20:08] <bollini> are we sure that there is a different behavior in data storage than pre 1.6?
[20:08] * 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:09] <bollini> or is it only a "duplicate" of the display issue?
[20:09] <mhwood> It does say "related to DS-553".
[20:09] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[20:09] <tdonohue> Anyone want to look into the #2 claim? (that behavior differs in 1.6?)
[20:10] <bollini> the reporter is Claudia, just ask for confirmation that there is a "storage" issue
[20:11] <tdonohue> ok. DS-554 -- ask for clarification from Claudia. Is there a storage issue, or is this a duplicate?
[20:11] <tdonohue> Deleting a role on the Edit Collection page causes the XMLUI to try and delete the associated group even if it is used elsewhere. : http://jira.dspace.org/jira/browse/DS-555
[20:12] <tdonohue> Oh, it looks like Robin Taylor is already working on DS-555 in preparation for 1.7
[20:12] <richardrodgers> +1 fix for 1.7
[20:12] <tdonohue> +1 fix for 1.7 as well (and we already have a volunteer)
[20:12] <mhwood> +1
[20:13] <tdonohue> DS-555 : Keep as is, schedule for 1.7, check with Robin for updates
[20:13] * mdiggory (~mdiggory@ip72-199-217-116.sd.sd.cox.net) has joined #duraspace
[20:13] <tdonohue> Statistics column and row labels not i18n: http://jira.dspace.org/jira/browse/DS-559
[20:13] <mdiggory> hello everyone
[20:13] <PeterDietz> I'll take 559, I meant to fix it for 1.6.2, but never got to it
[20:13] <PeterDietz> hi mdiggory
[20:13] <tdonohue> +1 -- any volunteers for DS-559
[20:14] <tdonohue> oh, thanks Peter
[20:14] <mhwood> +1
[20:14] <bollini> +1
[20:14] <tdonohue> DS-559 -- Assign to PeterDietz for 1.7
[20:14] <richardrodgers> +1
[20:14] <mdiggory> catching up on issues/log
[20:14] <tdonohue> DS-560 -- XMLUI news feature in dspace/config dir http://jira.dspace.org/jira/browse/DS-560
[20:15] <tdonohue> mdiggory: we're doing a JIRA review obviously :)
[20:15] <mdiggory> 560... we generally have switched within @mire to populating a set of new i18n fields for news and using those files as "templates"
[20:16] <mdiggory> the template just houses a div with a set of i18n tags
[20:16] <tdonohue> +1 to creating an Admin UI for DS-560, but this is a new feature, likely post-1.7
[20:16] <richardrodgers> DS-560 we need a design, along mdiggory's lines or other
[20:16] <tdonohue> mdiggory -- is this code you are offering to share?
[20:17] <mdiggory> its not very exciting...
[20:17] <mdiggory> but yes
[20:17] <kshepherd> hi all
[20:17] <tdonohue> ok, well in any case, sounds like DS-560 needs clarification, design & a volunteer
[20:17] <mdiggory> doesn't solve the larger issue of managing the content via the UI...
[20:17] <mhwood> Admin UI also gives us a chance to ensure that the page fragment will actually work within the pages where it is inserted.
[20:18] <tdonohue> Keep DS-560 open, look for a volunteer(s) and schedule for post-1.7?
[20:18] <bollini> the idea of move news file out of config dir is good too
[20:18] <mdiggory> I'm thinking post 1.7 and that there are projects that may enable more than this at that time.
[20:19] <tdonohue> DS-560 -- needs design, volunteers, schedule for post 1.7
[20:19] <tdonohue> DS-561 -- On login screen, keyboard input focus should be set to the first field (E-mail Address) so you don't have to use the mouse : http://jira.dspace.org/jira/browse/DS-561
[20:19] <mhwood> Yes, the config directory is a stew of different types of things used in different places and possibly managed by different people.
[20:20] <richardrodgers> +1 if someone will do cross-browser tests....
[20:20] <tdonohue> DS-561 is trivial...not a huge deal, but perhaps one less mouse click. Thoughts? Volunteers?
[20:20] <mhwood> Sounds like a small but potentially popular enhancement.
[20:21] <bollini> is there a way to do this without js?
[20:21] <tdonohue> bollini -- I don't think so (at least not as easily)...you need to use JS to call focus()
[20:22] <snail> bollini: without js you just have to hit tab a couple of times, i think
[20:22] <kshepherd> +1
[20:22] <kshepherd> what about "tabindex"?
[20:22] <PeterDietz> HTML gives a new ability <input maxlength="256" name="q" value="" autofocus>
[20:22] <PeterDietz> oops html5
[20:22] * dericed1 (~Adium@pool-108-14-205-86.nycmny.east.verizon.net) has joined #duraspace
[20:23] <tdonohue> sounds like most in favor of DS-561, volunteer to implement in JSPUI & XMLUI?
[20:23] <bollini> +1 kshepherd yes we should try with a tabindex
[20:23] <tdonohue> PeterDietz: yea, html5 offers a lot of new features ... but we aren't quite there (yet) :)
[20:23] <bollini> I can try on jspui
[20:23] <PeterDietz> xmlui has jQuery yes?, so that should help with being cross browser
[20:24] <kshepherd> bollini: it doesn't seem well documented but it's been in html for a long time, so hopefully can do the trick
[20:24] <mhwood> I'm sure I remember doing this without JS, but that's *all* I remember.
[20:25] <kshepherd> mhwood: tabindex!
[20:25] <mhwood> Probably.
[20:25] <tdonohue> I don't recall if JQuery is used -- there is some fancy JS within the new authority work, but I don't remember what that is
[20:25] <bollini> prototype
[20:25] * sandsfish (~sandsfish@dhcp-18-111-66-224.dyn.mit.edu) has joined #duraspace
[20:25] <bollini> I see jquery in discovery but I don't know if it is used
[20:25] <tdonohue> DS-561 -- schedule for 1.7. Bollini will do for JSPUI, needs a volunteer for XMLUI
[20:26] <PeterDietz> I'll do XMLUI
[20:26] <mdiggory> Discovery is using jquery for authocomplete support
[20:26] <tdonohue> Last one (for today): User with WRITE, ADD and ADMIN policy on collection cannot delete that collection due to bug in AuthorizeUtil.authorizeManageTemplateItem(context,collection) : http://jira.dspace.org/jira/browse/DS-562
[20:26] <mdiggory> plus some features from a solr javascript UI project
[20:26] <tdonohue> ok -- PeterDietz will do XMLUI for DS-561 -- thanks peter!
[20:27] <mdiggory> I don't recall xmlui utilizing tabindex, but others can correct me, it would be an enhancement to the interactive div templates to add such a feature there.
[20:27] <mdiggory> consolidating jquery into the share ui overlay would be keen
[20:27] <tdonohue> Any volunteers to investigate behaviour described in DS-562
[20:27] <bollini> yes, give it to me
[20:28] <tdonohue> ok -- DS-562, assign to bollini for further investigation.
[20:28] <tdonohue> we're now at about 30 mins, so I'd like to stop there for today and switch gears over to 1.7 discussion (we'll keep doing these JIRA reviews at the beginning of meetings till we catch up)
[20:29] <mdiggory> yes I have precisely 30 minutes before I have to leave the IRC channel
[20:30] <PeterDietz> I guess this is where I jump in and say dspace 1.7 is coming up, get all your work done
[20:30] <tdonohue> Ok, as I told PeterDietz today, I'm officially handing the reigns over to him (and taking a few steps back now)
[20:30] <tdonohue> haha :) good speech
[20:30] <mdiggory> hup! yes sir
[20:31] <tdonohue> So -- I added a few items to the agenda, which we may wish to go through : https://wiki.duraspace.org/display/DSPACE/DevMtg+2010-08-18
[20:31] <bollini> sir Peter can we start with discovery
[20:31] <PeterDietz> remaining from the last discussion was a few features that aren't likely to be finished in time for release
[20:32] <PeterDietz> So my fellow DSpace "Chosen Ones", lets start discovery, then move to REST
[20:32] <tdonohue> sounds good to me :)
[20:32] <kshepherd> discovery.... jspui? or just xmlui?
[20:32] <bollini> hopeful both
[20:32] * tdonohue looks towards mdiggory
[20:32] <mhwood> Hmmm, quickly, does anybody here use LNI, and can test AIP changes?
[20:32] <mdiggory> We do need to deal with the async/sync release process.
[20:33] <mdiggory> because otherwise we need to move all the discovery code into the trunk to support it.
[20:33] <tdonohue> mdiggory, why couldn't it be released as a module (like services is)?
[20:33] <mdiggory> dependencies on the core release...
[20:34] <bollini> should we support new discovery and old style browse/search?
[20:34] <mdiggory> services is not dependent on core (dspace-api) etc
[20:34] <kshepherd> mm..
[20:34] <tdonohue> So, the decision is either (a) move Discovery in with dspace-api, etc, or (b) modularize more, and move everything towards 'modules' area?
[20:35] <mdiggory> so, yes we can do the opposite... IE discovery can be installed into as dspace release (but only after the formal release)
[20:35] <richardrodgers> +1 modularize - I think dspace-api is too big already...
[20:35] <mhwood> If it's tightly dependent on core, doesn't it need to be part of core? If dependency is loose enough, does integration greatly matter?
[20:35] <mdiggory> but maintaining it in the modules directory and packaging it with the release, this is something we need to figure out how to fix
[20:36] <mdiggory> richardrodgers is right, so is mhwood
[20:36] <tdonohue> taking a quick step back -- first off, is Discovery "ready" for official release (I still haven't heard that one way or another)?
[20:36] <bollini> I think that it is useful provide it as module only if we want keep user free to choose
[20:37] <mdiggory> I think that discovery is still beta and while it works for our cases, it needs more eyes and evolution.
[20:37] <kshepherd> it feels stable to me, though there is some facet handling that would be better moved to solr schema instead of in the xmlui block, etc
[20:37] <mdiggory> its designed to be an "addon" to dspace to maintain that separation from core
[20:37] <mdiggory> so it can evolve
[20:37] <bollini> some work is needed, I see many hardcoded things from dryad in it
[20:37] <mdiggory> kshepherd: true
[20:38] <tdonohue> ok -- sounding less "beta" and more "experimental" then...at least as of today
[20:38] <bollini> there are common stuff that need to be shared between xmlui and jspui
[20:38] <mdiggory> bollini: point taken, some feautres were dryad centric, but can easily be generalized
[20:38] <kshepherd> because it's an "alternative" to ArtifactBrowser in xmlui, i feel like it'd be fine to be separate from core and maybe even release async?
[20:39] <bollini> the browse system is in the core
[20:39] <mdiggory> tdonohue: I don't think everyone realizes there is a JIRA project for it with tasks
[20:39] <bollini> we can't turn it off completely
[20:39] <kshepherd> bollini: true.. perhaps i'm just confusing things trying to tie it to xmlui
[20:39] <mdiggory> http://jira.dspace.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=10038&fixfor=-1
[20:39] <tdonohue> JIRA for Discovery : http://jira.dspace.org/jira/browse/DSCR
[20:40] <mhwood> Yes, if we offer a choice then there would be work to modularize ArtifactBrowser and its friends and relations.
[20:40] <mdiggory> mhwood: +10000
[20:40] <bollini> I have done some experiment and I'm able to replace discovery with dssearch easly
[20:41] <mdiggory> A good project would be to breakup things like RecentlyAdded and some other features out of things like CollectionView and CommunityView
[20:41] <bollini> we just need to make dsquery (sorry, not dssearch) more modular to allow plugin
[20:41] <kshepherd> yes.. i actually did that a while back, but i don't think i ever submitted a patch :/
[20:42] <kshepherd> i should still have it sitting around though
[20:42] <tdonohue> Ok -- so, mdiggory do you have a proposal/idea for how best to deal with Discovery release process (around 1.7), since this is the first real need for a potential async release? Should we discuss ideas in depth in one of next few meetings?
[20:42] <mdiggory> We are doing things like customized views build off of custom queries into Solr for things like Recent Items of Type X vs Recent Items
[20:42] <bollini> about browsing I'm thinking if it is possible to write a "SOLR DAO"
[20:43] <mdiggory> bollini: this is wha the services are for
[20:43] <mdiggory> There are SearchService, IndexService and a Solr Implementation
[20:43] <mdiggory> There are also StatisticsService etc with a similar client backing them
[20:44] <bollini> mdiggorry: yes, but I'm talking to implement a BrowseDAO so that we only need to put a configuration line in dspace.cfg to use solr instead of our browsetable
[20:44] <mdiggory> A Solr DAO would enable more fun things to happen in the Services Layer (more cores, searches for things other than items)
[20:45] <bollini> mdiggory: of course it could be useful also make a "BrowseService"
[20:45] <mdiggory> with Solr we encounter issues with some Browse features... but that is an interesting idea...
[20:45] <mhwood> How much of that can be done by 1.7? three months later?
[20:46] <bollini> I need to have solr in jspui stable before the start of October
[20:46] <mdiggory> what is the expected outcome of integration? Parity? (AGGHHH)
[20:47] <bollini> of course meet a project requirement is easier than meet community requirement
[20:47] <mdiggory> My concern with backing Browse by Solr is that its already a huge beast, and I'm trying to lighten the implementation
[20:48] <tdonohue> although this is interesting discussion -- don't we first need to figure out how to release Discovery (before we talk tighter integration, etc)? :)
[20:48] <mdiggory> I.E. even in the XMLUI, opening up AJAX support to Solr more directly and rendering search results / facets after the page is rendered
[20:49] <mdiggory> tdonohue: true...
[20:49] <mdiggory> Being on leave, I've taken a step back from development on it... but am returning to the table now
[20:49] <PeterDietz> do we want to get some REST discussion in before the end of the meeting?
[20:49] <tdonohue> It'd be nice to form a plan of next steps around Discovery -- if we need to figure out async releases because of that, that's also a good idea (but we need to bring a proposal or idea to the table to discuss)
[20:50] <mdiggory> There are more features in the works via NESCent.
[20:51] <mdiggory> wiring it into browse turns it (discovery) into two or more separate projects without async.
[20:51] <tdonohue> PeterDietz -- yea...I think we do :) REST may be similar to Discovery in that the code needs to be reviewed more, and may need some async release or modularization discussion
[20:51] <kshepherd> REST is far from ready. Even the read-only GET functions are not implemented as advertised, and GETs to, for example, collections with > 1000 items will run a typical jvm out of mem due to some parent/child entity loops and incorrect depth checking
[20:52] <PeterDietz> sure, I think Discovery is a bit more mature than the REST
[20:52] <bollini> we need to take caution... discovery is more stable but... there will be more eyes on it
[20:52] <tdonohue> kshepherd -- good to know. Maybe this means we need to start bringing REST project issues into JIRA and mark them to get 'fixed'
[20:53] <mhwood> +1 tdonohue
[20:53] <kshepherd> tdonohue: yeah that might be an idea..
[20:53] <tdonohue> but it also means we probably don't want to release REST in 1.7, unless someone has time to fix all it's issues :)
[20:53] <mdiggory> I don't think the code needs to be perfect for the decision to add it at this point, just that we agree on adding it as a feature and that there are things that need to still be fixed by the release
[20:54] <mhwood> How much work is needed to make it good enough to use, though it may want more polishing?
[20:54] <tdonohue> mdiggory -- correct, code need not be perfect right now...but, it needs to have a volunteer or voluntters working on getting it ready
[20:54] <PeterDietz> GSoC pencils down has passed, so if we want this code to make its way in, then its now a community project
[20:54] * bollini_ (~chatzilla@host223-235-dynamic.16-87-r.retail.telecomitalia.it) has joined #duraspace
[20:55] <mdiggory> PeterDietz is correct, we need to bring it forward as a community at this point.
[20:55] <tdonohue> +1 mdiggory
[20:55] <mdiggory> Its a similar problem to discovery, async release issues abound unless its moved under trunk
[20:55] <mdiggory> so again async is the issue.
[20:56] <tdonohue> I'm all for bringing the REST API forward -- I think it's an absolutely necessary feature these days -- I just don't know if I'll have much time in nearterm, but I may be able to chip in if others are
[20:56] <kshepherd> to get it to a working read-only (ie. no POST/PUT/UPDATE) by 1.7 should be possible but would still require a fair amount of effort and testing... time that i don't have :(
[20:56] <sandsfish> it needs some cleanup at the least. it was depending on earlier 1.6 code, which shouldn't be drastically different, but bears testing. there is also the major database hit when requesting URLs that traverse large portions of the repository. i've built it but have not had time to test yet.
[20:57] <tdonohue> mdiggory -- do you have ideas about possibly async processes that you'd be willing to write up or present to us in near future? I think we really need a 'proposal' to respond to, so that we can all get on the same page about it
[20:57] <mhwood> It sounds to me like 1.7 would be too ambitious.
[20:57] <sandsfish> i'd like to commit time to it, but i need to be sure i have time to finish the google scholar metadata project for review by the community.
[20:57] <mdiggory> those sorts of issues arose back int he DAO prototype as well and resulted in needing to refactor the DSpaceObject implementations to support less loading of children
[20:57] * stuartlewis_ (~stuartlew@s-lewis.itss.auckland.ac.nz) has joined #duraspace
[20:57] <mdiggory> I'll comment that LNI suffers similar issues with webdav
[20:57] <kshepherd> i don't really understand the reason for dependence on the sakai entitybus, etc. either...
[20:58] * stuartlewis (~stuartlew@s-lewis.itss.auckland.ac.nz) Quit (Ping timeout: 252 seconds)
[20:58] * bollini (~chatzilla@host223-235-dynamic.16-87-r.retail.telecomitalia.it) Quit (Ping timeout: 252 seconds)
[20:58] <mdiggory> kshepherd: AaronZ... we were working with the library as part of DSpace 2.0
[20:58] * stuartlewis_ is now known as stuartlewis
[20:58] * bollini_ (~chatzilla@host223-235-dynamic.16-87-r.retail.telecomitalia.it) Quit (Write error: Broken pipe)
[20:58] <mdiggory> ...ok, sorry, now really have to leave, will follow up when I return...
[20:59] * bollini (~chatzilla@host223-235-dynamic.16-87-r.retail.telecomitalia.it) has joined #duraspace
[20:59] <richardrodgers> bye mdiggory
[20:59] <mdiggory> bye
[20:59] <tdonohue> ok -- almost out of time here... I think there are still a lot of questions to be resolved, least of which is the async release idea
[20:59] <kshepherd> cheers mdiggory
[20:59] * mdiggory (~mdiggory@ip72-199-217-116.sd.sd.cox.net) has left #duraspace
[20:59] <PeterDietz> I don't think REST will get the eyes necessary if it lives in a separate branch, however it still needs work
[20:59] <kshepherd> fwiw, bojan has indicated that he's keen to still help out in the "community" phase of the REST module, so that's good
[21:00] <bollini> PeterDietz +1
[21:00] <kshepherd> but if i had to vote right now for 1.7 inclusion, i'd probably vote -1
[21:00] <PeterDietz> is there any way to get the "works as advertised" pieces of REST into trunk, and go from there
[21:00] <tdonohue> I'll say I'm committed to helping with REST -- I just wish I had the time in the next few months -- my time will likely be *after* 1.7
[21:01] <sandsfish> tdonohue: ditto
[21:01] <mhwood> Yes, there just aren't enough cycles for REST to go into 1.7. Mark it, "we really really want this post-1.7"?
[21:01] <tdonohue> mhwood -- yea, that may be the best idea for now, unless the cycles "magically appear"
[21:02] <richardrodgers> Remember 1.8 (or whatever) needn't e that far away - we are in a brave new world
[21:02] <tdonohue> As for Discovery -- sounds like the interest is there, but we need to figure out how to release it -- requires some async release discussions, which I can follow up with mdiggory on
[21:02] <PeterDietz> does 1.6.1 need to be bug fix only?
[21:02] <tdonohue> 1.7.1? :)
[21:03] * kshepherd looks dizzy
[21:03] <tdonohue> I'd recommend it -- I think in past making it have new features delayed our release of the next major version -- for instance, 1.5.1 and 1.5.2 having new features really delayed 1.6 (in my mind at least)
[21:03] <PeterDietz> oops, 1.7.1
[21:04] <bollini> why not include the rest code in the trunk and comment it before the release?
[21:04] <kshepherd> hm
[21:04] <richardrodgers> the point being?
[21:04] <kshepherd> i'd really recommend a few people checkout the module, build it, and test it a bit
[21:05] <bollini> this will give the idea that we are really interested in this project but it is not ready
[21:05] * tdonohue notices we are over time here -- we may need to wrap it up soonish
[21:05] <PeterDietz> the point being that you can develop with it easily, and make improvements as the code is in trunk
[21:06] <kshepherd> PeterDietz: it's so easy to grab and build anyway, i don't know if adding commented, bad code into trunk solves anything ;P
[21:06] <tdonohue> true -- but, if we are releasing off of Trunk, then it would be released (unless we create a 1.7.x branch before that period, and release 1.7.0 from the branch)
[21:06] <richardrodgers> in svn, sure, but why trunk? I can check out any branch/module, etc just as easily...
[21:06] <kshepherd> richardrodgers++
[21:06] <sandsfish> dspace-rest builds as a "droppable" webapp, so, it woudln't be too hard to just include it.
[21:07] <sandsfish> (i.e. include it in the webapps directory of a build)
[21:07] * 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:07] <tdonohue> +1 as well -- the code can be pulled down from the "modules" area already (like dspace-services) and others: http://scm.dspace.org/svn/repo/modules/rest/
[21:07] <mhwood> So it can be a sync. module now and become async. later when we figure out what that means.
[21:07] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[21:08] <tdonohue> One off topic question I really want to throw out there today -- any objections to requiring Java 1.6 for DSpace 1.7 release? I wanted to change our requirements in the main pom.xml, but wanted to check with others first
[21:09] <richardrodgers> No, it's a good idea I think - all our platforms have 1.6 available.
[21:10] <tdonohue> Ok -- I'll just make the pom.xml change -- if anyone has objections let me know :)
[21:10] <bollini> sorry to come back to discovery... but in an ideal world where discovery work for both jspui and xmlui, providing nice search and browse functionalities should we allow users to use the old system (lucene + custom browse system)?
[21:10] <tdonohue> We're well over time -- so, I'd like to close the meeting, unless there's anything else we need to answer today?
[21:11] <tdonohue> bollini -- my answer to that would be 'no'. I think we need to avoid supporting too many options (we just don't have enough developers). So, if Discovery was ever seen as the "default" or "best" way to do search/browse, then we would likely deprecate the old search/browse system
[21:12] <PeterDietz> I don't think that discovery (currently), does anything with communities and collections
[21:12] <kshepherd> you can view communities and collections, but they'll generally appear at the end of a long list of search results, yeah..
[21:13] <kshepherd> i do agree that some extra 'browse' functionality needs to be around..
[21:13] <bollini> this can be easly changed
[21:13] <mhwood> Sorry, I'm going to have to go. 'bye, all!
[21:13] * tdonohue All -- if you have to go, feel free :) sorry for running over today -- I'll stick around, as the discussion is still lively & interesting
[21:13] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has left #duraspace
[21:13] <kshepherd> (try doing community/collection management with discovery alone! i think i ended up re-deploying jspui for admin work :P)
[21:13] <richardrodgers> I've also got to go - bye all
[21:13] <kshepherd> cheers all
[21:13] * richardrodgers (~richardro@pool-173-76-18-245.bstnma.fios.verizon.net) Quit (Quit: richardrodgers)
[21:14] <bollini> say that discovery can be the only browse/search system for dspace (now, in 1.7 or in a point in the next future) is an important point to make design choices...
[21:14] <tdonohue> Yea, I think Discovery sounds promising, but still needs work (obviously). It's no where near ready to replace the current browse/search system. But, someday, maybe it would (if it ever had all the same features, etc)
[21:15] <PeterDietz> I think the discovery change might be to pull in parent (collection / subcom / community) and then it could facet those
[21:16] <bollini> the infrastructure for scoped search is already in place
[21:16] <bollini> you can make search within a community or a collection
[21:18] <bollini> I'm working on the search now, it could be possible to implement the same features of our current browse system fastly
[21:18] <bollini> sorry: I'm working on the browse now...
[21:18] <sandsfish> bye all
[21:18] <PeterDietz> so if someone want browse-by-title for a collection, thats discovery searching in scope of collection with some ordering
[21:18] * sandsfish (~sandsfish@dhcp-18-111-66-224.dyn.mit.edu) Quit (Quit: sandsfish)
[21:19] <bollini> yes
[21:19] * dericed2 (~Adium@76.15.234.164) has joined #duraspace
[21:19] <bollini> the most complex questions arise when you want browse metadata
[21:20] <bollini> browse for authors, subjects, etc.
[21:21] <bollini> particularly if you use the authority framework
[21:21] <PeterDietz> I would get rid of those, because those are just facet filters. Currently facet filters are sort by count. If you wanted to browse by author, that might be to change to sort authors by alphabetical
[21:22] <bollini> you can use the facet terms as browse list
[21:22] <bollini> you can sort facet terms by lex
[21:22] <bollini> alphabetically
[21:22] * dericed1 (~Adium@pool-108-14-205-86.nycmny.east.verizon.net) Quit (Ping timeout: 240 seconds)
[21:23] <bollini> the issue is that alphabetically is not enough
[21:24] <bollini> we need to work on the metadata value to get a sorted value
[21:24] <bollini> to make transliteration for example
[21:25] <bollini> my idea is to add extra fields to the solr document so to have a facet_browse field holding a complex value
[21:26] <bollini> sortvalue|||display value|||authority key (if any)
[21:27] <bollini> in this way, you can get the facets in lex order and build the right user interface
[21:32] <bollini> well, I think that is time to go for me... PeterDietz and any other interested in discovery please go ahead to discuss on the mailing list. I like to hear your idea about it
[21:33] * bollini (~chatzilla@host223-235-dynamic.16-87-r.retail.telecomitalia.it) Quit (Quit: ChatZilla 0.9.86 [Firefox 3.6.8/20100722155716])
[21:45] * dericed2 (~Adium@76.15.234.164) Quit (Ping timeout: 272 seconds)
[21:46] * keithgilbertson (~keithgilb@207.138.47.158) Quit (Quit: keithgilbertson)
[21:50] * dericed1 (~Adium@76.15.234.164) has joined #duraspace
[22:02] * tdonohue (~tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has left #duraspace
[22:07] * ksclarke (~kevin@adsl-39-10-103.clt.bellsouth.net) Quit (Ping timeout: 265 seconds)
[22:07] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: Connection reset by peer)
[22:07] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[22:10] * dericed1 (~Adium@76.15.234.164) Quit (Ping timeout: 246 seconds)
[22:15] * dericed1 (~Adium@76.15.234.164) has joined #duraspace
[22:24] * ksclarke (~kevin@adsl-39-10-103.clt.bellsouth.net) has joined #duraspace
[22:41] * dericed1 (~Adium@76.15.234.164) Quit (Ping timeout: 276 seconds)
[22:42] * ksclarke (~kevin@adsl-39-10-103.clt.bellsouth.net) Quit (Ping timeout: 240 seconds)
[22:45] * dericed (~Adium@76.15.234.164) has joined #duraspace
[22:46] * ksclarke (~kevin@adsl-39-10-103.clt.bellsouth.net) has joined #duraspace
[23:04] * dericed (~Adium@76.15.234.164) Quit (Ping timeout: 240 seconds)
[23:10] * dericed (~Adium@76.15.234.164) has joined #duraspace
[23:21] * ksclarke (~kevin@adsl-39-10-103.clt.bellsouth.net) Quit (Read error: Connection reset by peer)
[23:21] * ksclarke (~kevin@adsl-39-74-98.clt.bellsouth.net) has joined #duraspace
[23:31] * dericed (~Adium@76.15.234.164) Quit (Ping timeout: 264 seconds)
[23:36] * dericed1 (~Adium@76.15.234.164) has joined #duraspace
[23:59] * dericed1 (~Adium@76.15.234.164) Quit (Ping timeout: 264 seconds)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.