[
https://issues.apache.org/jira/browse/SOLR-344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12525287
]
Jonathan Woods commented on SOLR-344:
-------------------------------------
Hoss - I take on board a lot of what you say, and I appreciate the fact you
even skimmed the PDF without immediately accusing me of hubris! I'll come back
to you in a couple of days' time, when I've finished hacking my way through old
Lucene-based code I hoped to have (and maybe should have) thrown away.
> 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.
