Re: Solr Drivers

[Chris Hostetter <ho...@fucit.org>]

: Is there any interest in a Solr binary server-daemon in addition to
: it's HTTP interface/daemon?
: A generalized specification would have to be written that would listen
: on an alternative port from the HTTP interface.
: This binary interface would accept binary streams instead of 'strings'.
: A language-specific client driver would have to be written to support
: this specification. (my interest is in writing a PHP Pecl extension to
: implement the server interface/specification)

I guess my first quesion would be: why does this need to be a seperate 
port? ... we already have a binary format for updates/searches that works 
over HTTP, and it's pretty easy to deal with alternate formats (string 
based or binary) over HTTP using the RequestHandler+ContentStream or 
QueryResponseWriter APIs, so what exactly is it that you want to do using 
some binary format that isn't possible now?

: I realize  the HTTP interface is 'at the heart' of SOLR, but I think
: the benefits of language-specific drivers would be worthwhile.

Again, we already have langauge specific *parsers* and *formatters* -- 
it's not clear to me what types of langauge specific *transports* might be 
needed.

: The time taken to establish an HTTP connection, the overhead of the

this is what keep-alive is for.


My suggestion if you want to pursue this would be to implement it using 
the RequestHandler abstraction -- your custom request handler could have a 
trivial NOOP implementation of handleRequest, but during initialization it 
could spin up it's own port, speaking whatever protocol it wants.


-Hoss


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org