Carl-Adam Brengesjö wrote:

Hm, 439GB ... what is that guy sharing exactly? Piracy is a crime...
no, silly answer :)

The point is that unless you want to drive those with large shares and large filecounts away, any new query system (regexps) needs to be usable.

Any form of a more advanced query requires some time for execution (more or less). So how much time requires the query type suggested (fredrik was it, no?) ?
I'm not trying to promote regex now, just wanna know.

I don't care too much myself, my share is of a size that the number of hubs and number of searches/users does not load my machine at all.  However, that isn't the case for all users.  fusbar is one user (and list subscriber) for whom searches take up non-trivial amounts of CPU usage, on a respectable computer.

I can make a test with some various filelists. (C#, don't know C/C++ that good) Results coming up in a few days (or hours, depending how little I plan to sleep this night ;)

Like I said, I have real user's lists.  A bunch of them.  If you don't, go into a random hub and grab everyone's list.... Testing with made up data when real data is easily accessible is going to cast needless doubt on your conclusions.

These lists ARE standard. Unfortunatly, rar is not listed. And as so we can decide it (if we want to), as long the decition corresponds to the RFC's. And thus it can be, as Todd wrote, application/x-rar-compressed (RFC2046, page 9).
I say (if we use mimetypes) we use strictly standard, meaning if a client searches for "application/x-rar" - well bad for him if he dont get any results.
RFC2046 specifies that application/octet-stream should be used with "uninterpreted binary data". And doesn't rar files come under that category? :) If the user really wants to search for .rar files, well use the filename pattern instead!

Guessing/deciding non-standard MIME types on our own?  So if MIME searching doesn't totally replace the existing system, why make any new proposal more complex by including it?

- Todd