lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shalin Shekhar Mangar" <shalinman...@gmail.com>
Subject Re: [jira] Commented: (SOLR-567) SolrCore Pluggable
Date Fri, 05 Sep 2008 14:45:34 GMT
On Fri, Sep 5, 2008 at 7:59 PM, Mark Miller <markrmiller@gmail.com> wrote:

> These all sound like good ideas for solr2. The ability to handle changes on
> the fly easily across many machines would be an awesome place to reach.
> Dynamically changing field schema/stopword stuff is also a great feature to
> have.
>
> I think the key to reaching those goals is to really join the solr open
> source process and push at it a piece at a time. I think almost all of the
> features you have talked about make sense for the future of solr in one way
> or another. Take advantage of solrs popularity and I think eventually we can
> have more people helping make these goals a reality. It might not happen as
> fast as you'd like (already having all this Ocean code), but I think the
> long run returns will be much higher.
>
> You already have a great start with the patches and wiki info, but I think
> I am suggesting leaving the Ocean part out a little more, and maybe tackling
> these issues more form a Lucene/Solr perspective, using the Ocean ideas and
> code as leverage to move forward faster.


Mark has hit the nail on the head. We must start with the features which are
most relevant to our current set of users. Realtime Search is a need for
many. Cloud computing cluster having hundreds of servers is a niche area
limited to few (and they already have their systems in place without Solr).
Any efforts of integration must keep in mind our users and their needs.

Most Solr deployments have around 1-25 servers. We must start with that
use-case keeping in mind the grander goal. We should not be focusing on
building something that the developers want to build and use two years down
the line.

-- 
Regards,
Shalin Shekhar Mangar.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message