>>> Regardless of the path we go for building / shipping clustered search >>> solution. I'm mostly interested in the api's to the lower level lucy that >>> make it possible and how to make them better. >> >> Well, my main concern, naturally, is the potential burden of exposing >> low-level >> internals as public APIs, constraining future Lucy core development. > > It's a good concern, and I'm not certain what Dan is envisioning, but > I'm hoping that improving the API's means _less_ exposure of the > internals. Rather than passing around Searcher and Index objects > everywhere, I'd love to make it explicitly clear what information is > available to whom: if a remote client doesn't return it, you can't > use it. Instead of increasing exposure for remote clients, we'd > simplify the interface to local Searchers.
My vision would be something like, Core Lucy has API's exposed needed for cluster search client and server. Then we build a implementation of "ClusterSearch" build on top of Core Lucy. Regardless if the project is core/non-core it is built on top of well defined interfaces in Core Lucy. So Maybe Lucy Core does not require or use zeromq/MessagePack but "SearchCluster" does. And this is done by sub-classing Core Lucy and changing the serialization/message passing to work across the network. Mainly "ClusterSearch" doesn't get to cheat.. Anyone could build a different one with different properties/use cases and still be a first class citizen. -Dan
