On Tue, 15 Apr 2003, Douglas Smith wrote:
> Well, what I was thinking of is a property which contains numbers.
> Call it something like 'rankfactor' or 'swishrankfactor' which can
> be put in a meta tag in the html head. Then at search time, the rank
> is computed, and then this factor can be applied, just multipled
> to the computed rank.
That's a lot of disk accesses. So once swish gets its list of results it
would need to walk the list and read the property file for each
result. As it is now only the results that are displayed have their
A "better" way might be to build a big table in memory that can be
accessed fast. That's done when IgnoreTotalWordsPerFile (or whatever it's
called) is set to false -- an extra table is build and that's loaded into
A "more sensible" way would be to use a fast hash table on disk, I
> Is this a big design change? (Maybe, perhaps I should just go
> through the code myself before aksing for too much...)
Sure, you are welcome to enter the scary world of swish-e code. It's ugly
in there, but slowly getting better.
Bill Moseley firstname.lastname@example.org
Received on Tue Apr 15 22:56:07 2003