![]() |
How to react to a query? Is there a recommendation on how I should interpret a query? When looking at queries, people all seem to have there own way of searching. Say a query comes in like: bush clinton taft washington Probably, the person who entered this is looking for something on American presidents. He'd expect to get back something like the life story of bill clinton.pdf the life story of george bush.pdf To put it in other words, he's wants to search usign a OR operator. However, someone else will look for how to plant a bush.mpg and doesn't expect to get anything else back than that. He needs an AND operator, and doesn't care for the life story of george bush (can you blame him?) Any suggestions? Is there a *standard* in this? Also, some queries end on urn:sha1:HQ39875SDJHSF09FSDFSDF or something like that. Others appear to contain xml What should I do with them, since I assume these are applications-specific thingies. Must I try to interpret them? Thanx |
Hm... I have no idea but the queries are usually seen as OR. Maybe you should check out some sourcecodes of other clients to see how they solved the problem.... By the way Cakkie, Were you the who voted for my Lynn Cache on PlanetSourceCode? If you are that Cakkie, thanks! :p |
I don't know about other clients, but I use AND for the keywords. So "bush clinton taft washington" would not match "How to plant a bush". I do this to allow a bit easier filtering down by the end user, and the fact that an OR would return too many, perhaps mostly irrelevant results. The alternative would be by using commas. So "bush clinton" is "bush AND clinton"; but "bush, clinton" would be "bush OR clinton". This, because the comma is usually filtered by most clients. However, there's been several discussions about including Booleans or even REGEXP. As a matter of fact, I intend on using a GGEP extension for that, unless there's a wider accepted GGEP extension that comes out before that. |
Quote:
|
Quote:
Maybe I should implement some kind of cascading system: -->exact match --> Yes, return matches --> No, use AND --> Yes, return matches --> No, use OR --> Yes, return matches |
That's a good way to do it, if you can do that efficiently and fast. There's a LOT of queries you have to process, even on a low number of connections. |
Everthing needs to be efficient and fast though :) |
All times are GMT -7. The time now is 10:04 PM. |
Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2025, vBulletin Solutions, Inc.
SEO by vBSEO 3.6.0 ©2011, Crawlability, Inc.
Copyright © 2020 Gnutella Forums.
All Rights Reserved.