At 11:08 PM -0700 2/7/02, Neal Richter wrote: >What is the future of this code? I've read ill-understood (by >me) references to new searching/parsing code in previous posts. >... >I'm wondering if it wouldn't be easier to start with qtest.cc and >implement the 'hit' extraction if this code is going to get rewritten >massively.
Bingo. Unfortunately, neither Quim or I have had the time to devote to this project. Somewhere around here I have the additions to DocMatch which added the scoring functionality for the new htsearch. I'll find those and commit them soon. The basic idea is that qtest.cc will form the framework for a new htsearch. Much of the CGI input and command-line parsing in htsearch.cc is fine and can be moved as-is. Additionally qtest.cc needs to parse the search_algorithms attribute and set the OrFuzzyExpander appropriately. I should have time tomorrow to sit down and do that much since people seem to be interested in picking this up. For now, I'm going to ignore the collections and plug the ResultList directly into the current Display code. What else has been discussed as far as necessary cleanups and coding on the htsearch side? * Re-think collections (i.e. how should they fit into the framework cleanly) -- We're all willing to break collections for some period while we redo the rest of htsearch. * Improve the sorting algorithm for results -- Right now the entire list of results is sorted, regardless of how many are displayed. Much better to make a heap and pull them off as needed. * Clean up the Display class (not many specific details on this yet) * Add query and results caching -- Quim implemented some simple caching already, but an on-disk cache of recent queries would improve performance tremendously. -Geoff _______________________________________________ htdig-dev mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/htdig-dev
