Quote:
Originally posted by et voilą
ok Philippe, glad you got my idea  I was referring to kamdelia as it is the other alternative to the sheme I made as a proposal for requieries... ie I want LW to ABSOLUTLY include requieries. I just want to discuss with folks what way is the best. 
Ciao |
I don't want requeries... that's a difference. However it could be useful for the "looking for more sources" search after a download fails. Querying with a full URN may not be necessary, when we can simply look for sources with truncated URNs. However the problem is how to route such queries: QRP table contents would need to be changed... So I wonder if instead, we couldn't search by lists of precomputed QRP hash values (instead of strings). This would not fit in a classic search string due to its 32-bit binary values (where the least significant bits are cleared depending on QRP table sizes). In this case a search would be non-empty if just looking for these QRP hashes without any search string, which could as well be a QRP hash of the full SHA-1 URN (acting like a truncated SHA-1). This would go into a Query GGEP extension (search by keyword hash). It would be interesting mostly for long QRP keywords like URNs. If the query contains two hashes, it is exactly like two keywords and should match with the same policy (AND). With queries containing 4 hashes or more, 2 hash values on 3 should be enough to match.
Although I don't like requiries, there's a way to handle the number of keywords in queries, to look for alternative subsets of keywords in separate queries.