lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From acoliver <>
Subject Re: Re: Proposal for Lucene
Date Thu, 07 Feb 2002 17:10:43 GMT
>On Thu, 7 Feb 2002 06:52:26 -0800 Nelson Minar <> wrote.
>>This is just a few thoughts about Lucene.  Please send me your feedback,
>>critiques and thought.
>Interesting and well written! If I read this proposal correctly, what
>you're saying is "make Lucene more into an application, rather than
>just an indexing library".

No add those features.

>I *like* that Lucene doesn't have a spider, or a file tree walker, etc
>etc. It's conceptual simplicity. I agree it'd be useful to have easy
>applications built with Lucene, but should it be done as part of
>Lucene itself or as a separate project?

If these are encapsulated and in a different package, why does this
interfere with that?  

I think its best if this were in a Lucene top level package...
example org.apache.lucene.application.indexers.HTTPIndexer
(which I think should be called Crawler).

>In either event I think it's important to preserve Lucene's current
>library interfaces. If the primary interface into Lucene were via the
>proposed Indexer classes, I think Lucene would lose something.

This proposal is additive only.  Its not intended to replace anything.  The
only thing I might suggest (which I've tested locally) is providing an
AbstractDocument and making Document a default subclass.  I tested this
locally (and converting the referencing classes to use the abstract document
to reference it) and it worked great.  This might simplify adding document
filters.  Thats the only *change* I've suggested to the existing classes. 
But I tacked that on to the end as another option because I figured someone
had a real good reason to make Document *final*.

To reiterate, this does not seek to become the only interface to lucene.  To
draw a parallel: htDig has a htdig dev library.  This seeks to add the
features in another packages properly encapulated from the library except
where new/useful features might be added that are more appropriate to the
library.  (stating the obvious)

>..       .      .     .    .   .  . .
>To unsubscribe, e-mail:  
>For additional commands, e-mail:

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message