What about the Support for Search Term Highlighting? (see Maik Schreiber's paper)
It seems to have vanished from the list of features? ----- Original Message ----- From: "Peter Carlson" <[EMAIL PROTECTED]> To: "Lucene Developers List" <[EMAIL PROTECTED]> Sent: Thursday, May 23, 2002 8:29 AM Subject: VOTE: Possible features for next release > Hello all, > > Below is a list of all features that were requested/suggested for the next > release of Lucene. > > If you are in favor of the feature AND you are willing to help implement / > integrate and test it please put a +1 in the brackets. If you are against a > feature please put a -1 in the brackets and provide a reason. > > Note: Non committers can vote here, but at least 1 committer must be active > on the feature (i.e. willing to test and integrate it) for it to be part of > the next release. > > If something is unclear please let me know. Also, if people have suggestions > on a better way to organize this, let me know. > > --Peter > > -------------------------------------------------------------------------- - > > > [ ] Peter Halacsy's changes to the QueryParser that, I believe, make it > possible to programmatically specify a default operator (OR or AND). > > [ ] The recently submitted code that allows for queries such as "Microsoft > suc*" to match "Microsoft success" and "Microsoft sucks". > > [ ] Alex Murzaku contributed some code for dealing with Russian. > > [ ] A lady from Finland submitted code for handling Finnish. > > [ ] Japanese Analyzer ( Kazuhiro Kazama <[EMAIL PROTECTED]>) > > [ ] make package protected abtract methods of > org.apache.lucene.search.Searcher to public (I'd like to be able to make > subclasses of Searcher, IndexWriter, InderReader ) > > [ ] Term Vector Support > > [ ] add lastModified() method to Directory, FSDirectory and RamDirectory (so > it could be cached in IndexWriter/Searcher manager) > > [ ] support for adding more than 1 term to the same position (I'm sorry I > didn't find Doug's email about this) > > [ ] Does anyone see a problem with adding support for storing unindexed, > untokenized *binary* data as document fields? At the moment, the closest > thing we have is unindexed, untokenized *character* data. Looking at the > source, this will be a trivial change, but I'm curious to learn if there are > specific reasons (other than inclination and opportunity) that this has been > left out. > > [ ] Another feature could be the ability to retrieve the number of > occurences not only for a term but also for a Phrase (see > http://www.mail-archive.com/[email protected]/msg00101.html) > > [ ] Better support for hits sorted by things other than score. An easy, > efficient case is to support results sorted by the order documents were > added to the index. > > [ ] Support for results sorted by an arbitrary field. > > [ ] Add ability to "boost" individual documents/fields. When a document is > indexed, a numeric "boost" value could be specified for the whole document, > and/or for individual fields. This value would be multipled into scores for > hits on this document. This would facilitate the implementation of things > like Google's pagerank. > > [ ] Add to FSDirectory the ability to specify where lock files live and to > disable the use of lock files altogether (for read-only media). > > [ ] Add some requested methods: > String[] Document.getValues(String fieldName); > String[] IndexReader.getIndexedFields(); > void Token.setPositionIncrement(int); > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
