: 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: [email protected] For additional commands, e-mail: [email protected]
