[ https://issues.apache.org/jira/browse/SOLR-344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Klaas closed SOLR-344. --------------------------- Resolution: Invalid Let's move this discussion to the wiki and mailinglist. It isn't really an "open issue" for Solr. > New Java API > ------------ > > Key: SOLR-344 > URL: https://issues.apache.org/jira/browse/SOLR-344 > Project: Solr > Issue Type: Improvement > Components: clients - java, search, update > Affects Versions: 1.3 > Reporter: Jonathan Woods > Attachments: New Java API for Solr.pdf > > > The core Solr codebase urgently needs to expose a new Java API designed for > use by Java running in Solr's JVM and ultimately by core Solr code itself. > This API must be (i) object-oriented ('typesafe'), (ii) self-documenting, > (iii) at the right level of granularity, (iv) designed specifically to expose > the value which Solr adds over and above Lucene. > This is an urgent issue for two reasons: > - Java-Solr integrations represent a use-case which is nearly as important as > the core Solr use-case in which non-Java clients interact with Solr over HTTP > - a significant proportion of questions on the mailing lists are clearly from > people who are attempting such integrations right now. > This point in Solr development - some way out from the 1.3 release - might be > the right time to do the development and refactoring necessary to produce > this API. We can do this without breaking any backward compatibility from > the point of view of XML/HTTP and JSON-like clients, and without altering the > core Solr algorithms which make it so efficient. If we do this work now, we > can significantly speed up the spread of Solr. > Eventually, this API should be part of core Solr code, not hived off into > some separate project nor in a non-first-class package space. It should be > capable of forming the foundation of any new Solr development which doesn't > need to delve into low level constructs like DocSet and so on - and any new > development which does need to do just that should be a candidate for > incorporation into the API at the some level. Whether or not it will ever be > worth re-writing existing code is a matter of opinion; but the Java API > should be such that if it had existed before core plug-ins were written, it > would have been natural to use it when writing them. > I've attached a PDF which makes the case for this API. Apologies for > delivering it as an attachment, but I wanted to embed pics and a bit of > formatting. > I'll update this issue in the next few days to give a prototype of this API > to suggest what it might look like at present. This will build on the work > already done in Solrj and SearchComponents > (https://issues.apache.org/jira/browse/SOLR-281), and will be a patch on an > up-to-date revision of Solr trunk. > [PS: > 1. Having written most of this, I then properly looked at > SearchComponents/SOLR-281 and read > http://www.nabble.com/forum/ViewPost.jtp?post=11050274&framed=y, which says > much the same thing albeit more quickly! And weeks ago, too. But this > proposal is angled slightly differently: > - it focusses on the value of creating an API not only for internal Solr > consumption, but for local Java clients > - it focusses on designing a Java API without constantly being hobbled by > HTTP-Java > - it's suggesting that the SearchComponents work should result in a Java API > which can be used as much by third party Java as by ResponseBuilder. > 2. I've made some attempt to address Hoss's point > (http://www.nabble.com/search-components-%28plugins%29-tf3898040.html#6551097579454875774) > - that an API like this would need to maintain enough state e.g. to allow an > initial search to later be faceted, highlighted etc without going back to the > start each time - but clearly the proof of the pudding will be in the > prototype. > 3. Again, I've just discovered SOLR-212 (DirectSolrConnection). I think all > my comments about Solrj apply to this, useful though it clearly is.] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.