lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan <dmark...@gmail.com>
Subject Re: [lucy-dev] ClusterSearcher
Date Sat, 12 Nov 2011 20:14:30 GMT
>>> 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

Mime
View raw message