Ämne:Re: [dcdev] Searching
Till:[email protected], Direct Connect developers <[email protected]>, Carl-Adam Brengesjö <[email protected]>
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
"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
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.
450000000 )" provides simultaneously an enhanced query type and a querytype 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 :)
I know we are to discuss the actual protocol - but what's the point of
making a protocol that is not usable?
Also, you quickly want to find something.. dont want to sit 2minutes
configuring a criteria when it only takes 30seconds to scroll through