Just to expand on what you have already stated, Kelvin, Clemens and myself are putting together an application framework proposal that we are going to submit to the Lucene Dev list. The major idea is to include the benefits of document acquisition and pipeline approach of LARM, the indexing flexibility of Indyo and the integrated search/sorting functionality of the SearchBean.
There are a lot of issues to be worked out, but the main point is that we can build on the core Lucene API to create a framework.
As far as core API level features, I think there are few that are going to be added but some of the ones in the pipeline are
Term position support - lead on by Dmitry Serebrennikov
Analyzers for more languages - Various people
Built-in support for a Date and Number Fields - Lead by Brian, help by Peter
Configurable QueryParser Syntax (i.e. default operator, min # characters before wildcard, ...) - Still in design
As far as real core information retrieval features, I don't know the subject that well.
Common questions/issues to resolve:
Ease of updating and adding documents to live index
Better demo to show people how to use Lucene.
More documentation
--Peter
On Wednesday, October 30, 2002, at 11:31 AM, Brian Goetz wrote:
True, but I think some of these are better off as being their own projects or sub-projects, rather than part of the core. Its more of a question of visibility. One way to make them more visible/credible is to put them in the core, but that's not the only way to do so, and I'm not sure that's the best way.I think many of these ideas would be better served by combining them into a Lucene-based application framework, combining finding files to index (crawling), digesting them (format stripping), etc. It wouldn't have to be part of Lucene proper to be a very useful, flexible package. In fact, the issues at the application level are very different from the issues at the core search level and call for a different set of skills and perspectives. I think that a good goal for the core would be to encourage developers to build searching frameworks around Lucene so that no developer actually has to use Lucene directly (not to suggest that Lucene is by any means unpleasant to use directly.)
-- To unsubscribe, e-mail: <mailto:lucene-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:lucene-dev-help@;jakarta.apache.org>
