would be VERY helpful to be able to use search modes like what google offers.

for example, if you put quotation marks around a few words, the search will be for those words only when together in that order.

even better, if you could refine a search with a NOT function. for example, i recently did a search for music by a little-known band named Gramme. what i got back were 200 hits for Nelly's album Country Grammer. if I could have amended the search to rule out any entry with "nelly", i might have actually gotten what i was looking for.

not sure what others Google has, but those two have often been extremely helpful, and i imagine they wouldn't be hard to implement.

I think that's a good idea but it won't work reliable until ALL clients on the network have been updated.

+1 to the google-like searching.

trap_jaw, are there any operators that can be used for gnutella searches in LW, or are all search terms treated as AND's ?

(I've been confused in the past by results that seem to respond to path names, or index files inside packages. A search term like "limewire" returned 3000 results--the header also includes alternates-- in less than 10 seconds).

There are no operators yet. I think I'll write a patch for google-like searching soon.

Pathnames are included in searches, btw.

Thanks for the info; the patch sounds promising.

btw--is exposing path info really necessary, since I assume magnets don't require them? (just trying to understand).

<<I think that's a good idea but it won't work reliable until ALL clients on the network have been updated.>>

Unless you do the filtering at the receiving end. Sure, it would be nice to do it at the serving end and reduce traffic, but you could leave the "who has this" function unchanged and implement the filtering when the returned list is formatted for display.

We cannot do the filtering at the receiving end, because the query is also matched against the pathname - and that is not included in the result. A search for "artist - album - song title" may return a file named "song title.ogg". We would filter results like that, too.

Here are the operators, I had in mind so far....

+keyword : require keyword in filename (not just in the path or the meta data)
-keyword : require keyword NOT to occur in file- or pathname
!keyword : require exact keyword in filename ('!avi' will not match 'david')
"string of characters" : requires "string of characters" to occur in file- or pathname.

Note that it won't be possible to include a logical OR so easily - and personally, I don't really believe a logical OR is very useful.

Agreed, but since we're querying the entire network it's unlikely the other programs will change their protocol in a timely manner, which was your original point. But the not function would still work when used at the receiving end. True, it wouldn't filter undesired files that have been renamed, but most aren't, and it would be useful in filtering the unwanted porno responses when searching for the movie Holes. And it would have worked in the example given in the first post in this thread.

Jay