lucene-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Kubes <ku...@apache.org>
Subject Re: [VOTE] merge lucene/solr development (take 3)
Date Tue, 09 Mar 2010 06:10:18 GMT
I believe this is a question of identity.  What is Lucene?

IMO Lucene is a full text search library, that is it's purpose.  It 
isn't trying to be a search server or a search engine.  It is easy to 
include as a library and is used on everything from embedded servers to 
www search engines.

Quoting from Yonik's previous posting:

 > Some in Lucene development have expressed a desire to make Lucene more
 > of a complete solution, rather than just a core full-text search
 > library... things like a data schema, faceting, etc.  The Lucene
 > project already has an enterprise search platform with these
 > features... that's Solr.

So is Lucene a full text search library or is it something different? 
And isn't that something different already Solr?  Why should they be the 
same thing when their goals aren't the same?

 > Trying to pull popular pieces out of Solr
 > makes life harder for Solr developers, brings our projects into
 > conflict, and is often unsuccessful (witness the largely failed
 > migration of FunctionQueries from Solr to Lucene).

I feel for you, really.  I remember trying to develop in Nutch on Hadoop 
0.04.  But the logic is not correct.  Just because Solr wants X feature 
and Solr uses Lucene != everyone who uses Lucene wants X.  Faceting for 
example, great feature, but not useful in every full text search.

 > For Lucene to achieve the ultimate in usability for users, it can't
 > require Java experience... it needs higher level abstractions provided
 > by Solr.

I don't believe this to be true.  If the Lucene community had wanted 
very general language agnostic search, it would have happened by now. 
Lucene is a Java API.  Solr on the other hand is a server and therefore 
should be language agnostic.

 > The other benefit to Lucene would be to bring features to developers
 > much sooner... Solr has had features years before they were developed
 > in Lucene, and currently has more developers working with it.

"We have more developers than you do" isn't a valid reason to merge, 
especially in open source software.  Maybe in the corporate world.  IMO 
if Solr has more developers and want some architecture changed in Lucene 
and it is to the benefit of the entire Lucene community, then those 
changes can be proposed and voted upon.

 > Esp with Solr not using Lucene trunk, if a Solr developer wants a
 > feature quickly, they cannot add it to Lucene (even if it might make
 > sense there) since that introduces a big unpredictable lag

Solr has the option of not using Lucene.  If something needs to go into 
Lucene, it should be voted on and support all of the different uses for 
Lucene.  As a friend told me recently, specialization is for insects.

 > 1) Solr would go back to using Lucene's trunk

Use trunk, don't use trunk.  That is up to the Solr project.  It 
shouldn't influence Lucene's behavior.

 > 2) For new Solr features, there would be an effort to abstract it such
 > that non-Solr users could use the functionality (faceting, field
 > collapsing, etc)

Can you say that every feature would be applicable to a full text search 
library.  If not then it is beyond the core responsibilities of Lucene.

 > 3) For new Lucene features, there would be an effort to integrate it
 > into Solr.

No.  Because by specializing towards Solr, or Nutch, or any of the 
hundred other applications that use Lucene, it looses its general 
applicability.  Where would Hadoop be if it never made it past Nutch?

 > 4) Releases would be synchronized... Lucene and Solr would release at
 > the same time.

So synchronize your releases.  Communicate.

I am open to listening to your responses, but all of this is to say my 
vote is still currently -1.

Dennis

Mime
View raw message