Hi,

Alot of discussion has been focused on search commands and it's features.
I don't think we need (nor should) do it too complex and with many
features.

perhaps it is because it is the main feature (in both user usage and bandwidth load).

"SEARCH <dest[:port]> <id> <mime> <size|#[type#]hash> :<pattern>\r\n"

The first 3 arguments are given, no discussion there.
(destination must be a ip with port for active search and for passive it
is the client's GUID or name... whatever will be used).
The fourth argument can be for two uses. either a size (range) or a
hash. If it's a hash it must begin with a # char.
Next comes the pattern (wich can contain spaces, therefor the : to tell
the beginning of the message).
Pattern can also have two meanings, either it can be a regex (poisix or
perl, doesnt matter) or it is the exact (or wildcarded) name of the
file. Clients can decide, upon submitting, if they want to replace
spaces with a * to work the way searching currently does.
To tell a regex from name the work is simple - as no filename on a
filesystem can contain directory delimiters and therefor noone can
search for one, we simply add them in the beginning and end of the
regex. And woila, we still have a valid regex: "/pattern goes here/" :)
(some regex libs cant handle the / /, but it's easy to filter out by the
end-client).

I think (but it is only my opinion) there is too many problems with this description. 1) the mime is useless because most of the time, clients do not share a common database with known values and I don't speak about OS (windoz knows mime types ?). Moreover, below, you speak about "simple" users that are just able to do basic queries ... do you think they now mime types ? and what is the mime type of the current "any" type (when a user is search for an album (mp3 and covers)).
2) the size/hash part is embedable as pattern (except if you mean 'file pattern' and not just 'pattern').

No need for fancy if-statements and such in the search query. A user
mostly just searches for a name anyway and goes through the results
manually, it's the quickest and most userfriendly. Ok - it's simple to
write a if-statement yourself.. but imagine a gui to that.. to be able
to make a complex if statement without actually write the if statement
it would require alot of controls. As per my example you only need a
single text field. Pherhaps you like to some checkboxes to tell if you
want it as a regex, wildcard of plain to ensure syntax before sending
the request to save traffic, but this is optional.

I hope I won't seem to be to (too) rude but it is too simple for me and I like complex things :) The protocol should not limit software evolution. What you propose looks a lot like the current search query with very few modifications and if it is true a lot of users only use a small set of features (who says mickey$oft office :) ), this does not mean some other do not need more.

The previous suggestion "( N =~ avi$ || N =~ ogm$ ) && ( T =~ ^video/ ) && ( S

450000000 )" provides simultaneously an enhanced query type and a query

type that can evolve without breaking "syntactic compatibility" with previous client (supporting the same query scheme). You even have encountered a limit of your own suggestion with your "Perhaps ..." because if you start to add new features by breaking the previous protocol definition 2 minutes after its creation, I don't want to imagine the result after 6 months :)

About the GUI having problem to create big patterns, I think it is a fake problem. IMHO, a GUI should not create big patterns, it should provide a simple search support (a bit like the current one). This search form will be used by most of the users (including expert ones when they don't want to do weird things). On the other side, the GUI should provide an input field allowing expert users to create their own query (manually or with the help of the GUI). Your way of describing the search problem looks like mickey$oft way of programming: I will program with my mouse :) Honestly, I have never seen a program working with such a method.

I know we are to discuss the actual protocol - but what's the point of
making a protocol that is not usable?

At least, we agree on something :)

Also, you quickly want to find something.. dont want to sit 2minutes
configuring a criteria when it only takes 30seconds to scroll through
100+ results.

Not really a good example because IMHO, a client should provide a default configuration allowing a basic user to perform search like you describe it (see above).

Eric
DCTC/dchub