Postponing Ocean Integration towards 2.0 is not a good idea. First of all we do not know when 2.0 is going to happen. delaying such a good feature till 2.0 is wasting time.
My assumption was that Actually realtime search may have nothing to do with the core itself . It may be fine with a Pluggable SolrIndexSearcherFactory/SolrIndexWriterFactory . Ocean can have a unified reader-writer which may choose to implement both in one class. A total rewrite has its own problems. Achieving consensus on how things should change is time consuming. So it will keep getting delayed. If with a few changes we can start the integration, that is the best way forward . Eventually , we can slowly , evolve to a better design. But, the design need not be as important as the feature itself. On Fri, Sep 5, 2008 at 6:46 PM, Yonik Seeley <[EMAIL PROTECTED]> wrote: > On Fri, Sep 5, 2008 at 9:03 AM, Jason Rutherglen > <[EMAIL PROTECTED]> wrote: >> Ok, SOLR 2 can be a from the ground up rewrite? > > Sort-of... I think that's up for discussion at this point, but enough > should change that keeping Java APIs back compatible is not a priority > (just my opinion of course). Supporting the current main search and > update interfaces and migrating most of the handlers shouldn't be that > difficult. We should be able to provide relatively painless back > compatibility for the 95% of Solr users that don't do any custom > Java.... and the others hopefully won't mind migrating their stuff to > get the cool new features :-) > > As far as SolrCore goes... I agree it's probably best to not do > pluggability at that level. > The way that Lucene has evolved, and may evolve (and how we want Solr > to evolve), it seems like we want more of a combo > IndexReader/IndexWriter interface. It also needs (optional) > optimistic concurrency... that was also assumed in the discussions > about bailey. > > -Yonik > -- --Noble Paul
