Say we were to come up with a FacetResult class... it would be
undesirable to have to add support in the response writers for
specific classes that will keep growing over time. So I guess a
FacetResult class would have to tell the writers how to access that
info, or export some sort of generic interface that served the same
purpose as the NamedList does now.
I think we are getting to something like this with the seach component
idea (SOLR-281 -- still a stub). While components could interact with
each other by putting stuff in a Map<String,Object>, it seems better to
have a strongly typed class that does core functions so each component
can easily inspect what has happened/needs to happen.
But I think two things need
to happen here: (i) the work here should be moved into org.apache.solr,
because with the right API at the server end you don't _need_ any code for a
Java client - it would just call into the API,
The Java client was meant primarily for remote querying of solr... but
it can be transparently used locally.
Solrj is designed to be able to keep the same interface for local or
remote access.
In general I think solr (the core) should be designed and optimized for
high concurrency HTTP server. In my view, its fine if smaller scale
embedded applications need a little contortion if the design choice
makes the most sense under heavy load.
Any thoughts?
I'm certainly not against moving toward nicer internal Java APIs (but
back compatibility is an issue here), but I think the external APIs
are much more important.
As for a major refactoring... my first patch for solr was essentially a
HUGE refactoring of everything to make it "better" -- after working
through the integration process and understanding apache release
structure, I realize the value in a strict API. When we move to solr
2.0, there is more room to change the API - until then, backwards
compatibility is a top concern.
That said, I see nicer new APIs emerging as the need to string functions
together becomes more pressing (SOLR-281). Features like faceting,
MoreLikeThis, field collapsing will need to be able to share well typed
data. If you are looking for a place to contribute, this would be a
good place to start. I am also looking to have the embedded solrj
client work directly with the NamedList result rather then transform:
NamedList -> XML -> NamedList
ryan
