Chuck Williams wrote:
This is a nice solution! By having MultiSearcher create the Weight, it can pass itself in as the searcher, thereby allowing the correct docFreq() method to be called. This is similar to what I tried to do with topmostSearcher, but a much better way to do it.
This still wouldn't work for RemoteSearchables, except if you allow call-backs from each RemoteSearchable to the MultiSearcher.
I don't see what callbacks are required. When the Weight is constructed it invokes docFreq for each term, which, if RemoteSearchables are involved, will result in IPC calls to those RemoteSearchables. Then, the Weight object is serialized to each RemoteSearchable and a TopDocs is returned. Where are the callbacks? These are only required for HitCollector-based methods, which are not advised with RemoteSearchable.
For this, MultiSearcher would have to be remotely callable, too.
A MultiSearcher can be made remotely callable by wrapping it in a RemoteSearchable, if that's required. But I'm not sure that's your concern here.
As I said above, IMHO we should stay with a simple client/server model here.
I think we would still have a simple model, unless I'm missing something.
Doug
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]