[Search-l] Processing from mulitple indexes...

[Jeremie Miller]

Heh, that's almost exactly how the JS behind the current re.search  
stuff works, it's pulling in and merging between two indexes currently  
(nutch and KT contribs, and another recent idea is to build a third  
index of just page summaries so we can fit more into our limited  
resources).  One of our important principles is to try and use only  
open-source-built and freely-licensed indexes too :)

The "widgets" (or whatever you want to call them) discussion is very  
close to this also, triggering the merge of other custom results into  
any search, and there's some working going on now to clean up the JS  
to support this even better.

Jer

On Sep 3, 2008, at 3:45 PM, Aerik Sylvan wrote:

> Crossposting this - not sure of the best home for it...
>
> So, we have the the beginnings of code and a framework that really  
> facilitates multiple indexes, with factories and brokers and  
> collectors... How about moving the processing of the final result to  
> the client?  In other words, meta search via javascript.  You get a  
> lot of nifty things with that architecture - one of the big bits is  
> that it reduces the server resources needed to aggregate results.   
> It increases bandwidth, becuase you'd need to server perhaps the top  
> 100 results from each index you're querying, and let the client  
> whittle them down to the top 10 combined result.
>
> Anybody working/thinking in that direction?
>
> (Had this thought for awhile, but the news of Google Chrome's js  
> engine being 10+ times faster makes it even more intriguing).
>
> Best Regards,
> Aerik
>
> -- 
> http://www.wikidweb.com - the Wiki Directory of the Web
> http://tagthis.info - Hosted Tagging for your website!
> _______________________________________________
> Wikia Search mailing list
> http://re.search.wikia.com/
> Change options or unsubscribe: http://lists.wikia.com/mailman/options/search-l