It just dawned upon me that "url_seed_score" might be a better name than "url_adjust_score". Calling it "url_weigh_score" (a tiny bit better than "url_adjust_score" IMHO) would make it confusingly similar to "url_weight_score" (and vice versa). Not sure if there's not a better name around the corner. Your suggestion is welcome. Or perhaps it should just be called "attribute7" :-) Guessing the N and M in *N+M seems to be harder than anticipated. If one always want hits in one area come before another, it seems suitable to add 2e6 to its scores, since scores easily come in the 1e6 range. That seems a little bit high, so I'll probably have to investigate score calculation a bit more than I wanted ;-) Another thing: In the 3.1.x series and 3.2.0, Display took care of all the score-calculation after a list of hits was retrieved. In the main trunk, there's a new class Searcher, supposedly taking care of finding and generating a list of hits. But full OO-glory was not achieved; Display still sorts and calculates parts of the scores for the list it is handed. Intuitively, a class called Searcher should do all the grunt work and neatly wrap up a list that a class called Display "decorates" and outputs. (Perhaps another class in between, but continuing that kind of "struggle of the classes"-thinking quickly gets out of hand and nowhere fast.) Why do I bother with this? Well, *most* calculation for ..._factor:s are carefully calculated in Searcher::score, after an initial hit-list is composed. Then Display::buildMatchList comes and deletes all urls in "exclude" and not in "restrict"! Which probably removes a lot of URLs. It goes on to do the remaining score-calculation, for "date_factor" and "backlink_factor". This just seems a bit arbitrary. For score-seeding, this means that I'd have to put it in Display::buildMatchList, which would be adding badness to the situation, or move the calculations for date_factor and backlink_factor into Searcher::score, which would be a half-assed change IMHO. I'd rather "clean up" Display and Searcher some more. One basic thing would be to move the buildMatchList method to Searcher, perhaps replace it and Searcher::score() with other methods, as it fits. Anyone opposed to this? brgds, H-P ------------------------------------ To unsubscribe from the htdig3-dev mailing list, send a message to [EMAIL PROTECTED] You will receive a message to confirm this.
