eric writes:
> > > Personally, I believe that the more advanced filtering should be left
> > to the client that recieves the results, to relieve the search
> > algorithm a bit.
> > I think the search syntax must be as powerful as possible to reduce network > load (for both clients and hubs).

That is true, of course; I had not thought of that. I'll ramble more
about this further below.

> > I would also _love_ to see regexp searching, but I guess the Windows
> > folks won't be too fond of that. If it would come to pass, I would use
> > a SRCH command like this instead, where all parameters are always
> > "and"ed (removing comparison groupings do relieve clients a lot, as
> > well):
> > I also agree, regexp is cool :) but I also think windoz users are more > familiar with standard windoz wildcards.

While that's true, I don't think it would be such a great problem to
translate glob patterns into regexes. Just replace '*' with '.*' and
'?'  with '.'.  Match ranges are just left as they are. The client can
do that before sending the search request.

> > SRCH N~(.mpg|.avi)$ S>350M S<700M
> >
> > For those who aren't used to regexps, they also allow some pretty
> > interesting stuff. For example, take a very popular series like Ranma
> > 1/2, which has lots of variants. If I want to search for episode 5 of
> > season 4 and want to avoid sizes below 100MBs (to get rid of the
> > dubs), I could use this to make sure I get the right one:
> >
> > SRCH N~ranma[^0-9]*4[^0-9]+0?5[^0-9]*.avi$ S>100M
> > <very serious mode>
> Why not using something more powerful like expression that can be processed by > perl ( you are not very far with your N~ and S> ). Only few things are > missing like &&, || or parenthesis.
> </very serious mode>

I have nothing at all against using PCRE instead of POSIX RE, if
that's what you mean. And sure, I can most certainly agree to using a
full-sized expression syntax; a parser can be written in five minutes
using flex and bison anyway (and with a word based protocol, you
probably won't even need flex).

Basically, you just need to define some basic criterias that can be
specified by the syntax that don't use too much CPU, like substring
matching (or, rather, regex matching), size comparison, hash
comparison.

What do you say? How about a full search expression syntax? I won't be
against it, at least; bandwidth is a very important issue, especially
if you use UDP to deliver the results.

> With this, I agree to vote for your protocol :-)

Really? Are you serious?

Fredrik Tolf