lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Carlson <carl...@bookandhammer.com>
Subject Re: Development plans for Lucene?
Date Wed, 30 Oct 2002 19:52:01 GMT
Brian,

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>


Mime
View raw message