You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Peter Carlson <ca...@bookandhammer.com> on 2002/05/23 17:29:17 UTC
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 <ka...@ingrid.org>)
[ ] 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/lucene-dev@jakarta.apache.org/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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Possible features for next release
Posted by Julien Nioche <Ju...@lingway.com>.
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" <ca...@bookandhammer.com>
To: "Lucene Developers List" <lu...@jakarta.apache.org>
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 <ka...@ingrid.org>)
>
> [ ] 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/lucene-dev@jakarta.apache.org/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:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>