Right you are Hardy. My only point was, we'll *trust* that there are no issues present that are caused by running the feature for longer time-periods than the test-a-thon provides.
But I agree, I think this could be deferred since it is just a configuration flip for the most part to enable Discovery (right?), unless others have a good reason why we need to lock it in early. Personally, I don't see any. -Sands On Aug 23, 2012, at 1:50 PM, Pottinger, Hardy J. wrote: > Hi, well, to be fair to Approach #3, we're likely going to be testing all > these features during testathon *anyway* even if the default will be > "Discovery Off." If this is indeed the case, I think it's a decision we > can either safely defer until after testathon, or revisit after the > testathon, no matter what your attitude towards caution may be. ;-) > -- > HARDY POTTINGER <pottinge...@umsystem.edu> > University of Missouri Library Systems > http://lso.umsystem.edu/~pottingerhj/ > https://MOspace.umsystem.edu/ > "Genius? Nothing! Sticking to it is the genius! I've failed my way to > success!" --Thomas Edison > > > > > > On 8/23/12 12:40 PM, "Sands Alden Fish" <sa...@mit.edu> wrote: > >> Approach #1: Hold off on judgement of this until we have all of the >> Discovery contributions merged and running. There have been a lot of >> modifications in both the XMLUI & JSPUI side of things. Stability of >> these incarnations of Discovery at this point >> is conjecture. >> >> >> Approach #2: Default to off for 3.0, plan on default on for 3.1. If >> history is a guide, it won't be too long until we have a 3.1 bug fix >> release out. This would allow us to see what kind of stability we get >> over the long-term (month++) and iron out >> any bugs. >> >> >> Approach #3: Caution be damned, just enable the thing and trust that the >> test-a-thon will catch anything important. (Since architectural >> components are being introduced as part of this feature (Solr and new >> code that interacts with it) I tend to not >> favor this approach (IMHO) because test-a-thon work-overs don't tend to >> shake out up-time stability issues, i.e. cumulative bugs that appear only >> after a resource leak or the like has been allowed to build up to an >> error state.) >> >> >> This is just off the cuff. What are some other approaches or thoughts? >> >> >> >> -- >> sands fish >> Senior Software Engineer >> MIT Libraries >> Technology Research & Development >> sa...@mit.edu >> E25-131 >> >> On Aug 23, 2012, at 1:16 PM, Tim Donohue wrote: >> >> >> Hi All, >> >> This topic came up in yesterday's Developers Meeting, and we all felt it >> worth posting to the dspace-devel list for feedback. >> >> Question: Should Discovery (Solr search/browse) be enabled by default in >> 3.0? >> >> == What would this mean? == >> >> It'd mean that Discovery faceted search/browse (backed by Solr) would be >> the default search/browse interface in 3.0. Users would still be >> welcome to disable Discovery and use the Legacy Search & Browse >> mechanism (backed by Lucene & the database), and we'd provide clear >> instructions on how to do so. >> >> Discovery could be enabled by default for just XMLUI or for both XMLUI & >> JSPUI (see below for more). >> >> == Some possible "Pros" == >> >> * Discovery has been around since 1.6 (for XMLUI) and is becoming much >> more mature >> >> * In 3.0, Discovery will be getting even more exciting features, >> including "search snippets", "hit highlighting", "more like this" >> recommendations, etc. See this JIRA ticket for more details & >> screenshots: https://jira.duraspace.org/browse/DS-1229 >> >> * Also, there is a high probably that in 3.0, Discovery will also be >> available for the JSPUI. (Please note this hasn't officially been >> decided, but the work looks promising so far based on early feedback.) >> This work is being done by CILEA and is described at: >> https://jira.duraspace.org/browse/DS-1217 >> >> == Some possible "Cons" == >> >> * The JSPUI + Discovery work is still very "young". This may mean we'd >> want to closely consider whether Discovery is ready to enable by default >> for JSPUI. >> >> * Discovery does require the DSpace "solr" web application to be >> installed/enabled in Tomcat. This is a separate webapp which sits >> alongside "xmlui" and "jspui". So, if we enable Discovery by default, we >> need to make clear in the Documentation that the "solr" webapp is needed >> to make the XMLUI and/or JSPUI run properly. >> >> >> What do you think? Is this worth considering for 3.0? Would you like to >> see Discovery enabled by default or should we keep it disabled by default? >> >> - Tim >> >> -- >> Tim Donohue >> Technical Lead for DSpace Project >> DuraSpace.org >> >> -------------------------------------------------------------------------- >> ---- >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> Dspace-devel mailing list >> Dspace-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/dspace-devel >> >> >> >> >> > ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
