On Fri, Sep 5, 2008 at 7:23 PM, Mark Miller <[EMAIL PROTECTED]> wrote: > IMO, you are underestimating the difficulty of integrating Ocean with Solr's > current API's. OK. you are right. Actually ,I did not mean the ocean integration. I am mostly interested in the Realtime search part. If we take one baby step at a time it may be easy for us . We can add features one by one, but why don't we start with realtime search? (this sounds like an immediately useful feature to an average solr user). > > Also, Jason has already mentioned that Ocean is much more than just realtime > search. Adding realtime search to something like solr 1.5 is a different > goal than possibly integrating the Ocean work that has been done / is > planned, which seems like a very large scope project and if done would > certainly seem to merit a 2.0 change in its own right. > > Still seems large and nebulous to me at the moment...just like solr 2. They > go well together in my mind <g> > > Noble Paul നോബിള് नोब्ळ् wrote: >> >> 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
