Seach.File Type: >Any Non MP3 file<

Archived discussion about features (predating the use of Bugzilla as a bug and feature tracker)

Moderator: Moderators

Locked
NanoFusion
Posts: 2
Joined: 2003-04-20 21:27

Seach.File Type: >Any Non MP3 file<

Post by NanoFusion » 2003-04-20 21:39

Please Add this category under File Type, so that it filters out .mp3 files:

Any Non MP3 file

Thanks

Kenneth-Chile
Posts: 80
Joined: 2003-03-21 10:17
Location: Concepcion, Chile.

Post by Kenneth-Chile » 2003-04-20 22:28

I think the solution is more general: Selective search. Search with NOT value.

Example:

file_name_you_want -.mp3 (minus .mp3)
Althought minus char is an imprescindible char.

What about slash symbol(/)? The search would be:

item_name_you_want /any_text_you_want_to_exclude
for many texts: item_name /t1 /t2..../tn

Example:
pearl jam /live
pearl jam /mp3 /avi /jeremy

etc, etc.
This is only one way to make it. It could be a graphical solution, like a text box for exclude text, whatever.

I think is a good idea ? What do you think :shock:

Another question? Is it possible, that when search finds mp3 files, that it shows the quality property(kbps of mp3)? :?

Kenneth
In Theory, there is no difference between Theory and Practice. In Practice, there is.

sandos
Posts: 186
Joined: 2003-01-05 10:16
Contact:

Post by sandos » 2003-04-21 03:34

Or, even more general: make a simple stack-based query language (I believe G2 has this, maybe G1 aswell)

Kenneth-Chile
Posts: 80
Joined: 2003-03-21 10:17
Location: Concepcion, Chile.

Post by Kenneth-Chile » 2003-04-21 03:40

I said:
Kenneth-Chile wrote:This is only one way to make it. It could be a graphical solution, like a text box for exclude text, whatever.
I wanted to say: "This is not the only one way to make it."

Sorry :oops:
In Theory, there is no difference between Theory and Practice. In Practice, there is.

cologic
Programmer
Posts: 337
Joined: 2003-01-06 13:32
Contact:

Post by cologic » 2003-04-21 04:47

Regexes without backtracking?

Kenneth-Chile
Posts: 80
Joined: 2003-03-21 10:17
Location: Concepcion, Chile.

Post by Kenneth-Chile » 2003-04-29 20:34

I liked Moglo Solution:

value1 value2 : This will search for something that contains both words.
value1 -value2 : This will search for somethig that contains value1, but not value2
"-value1" : This will search for something that contains -value1
In Theory, there is no difference between Theory and Practice. In Practice, there is.

Moch
Posts: 71
Joined: 2003-03-21 22:29

Post by Moch » 2003-04-29 21:46

Hmmm MoGlo must parse the search results after it gets them to get it on such a fine tuned level.... It would be a lot nicer if it was incorporated in the protocol though so clients would filter the results before they were sent back. (less load on the network that way)

~Moch

Melkor
Posts: 24
Joined: 2003-02-23 03:38
Contact:

Post by Melkor » 2003-04-29 23:14

true...
but that would require adding to the protocall.
It would only at first work with DC++ & derivatives.

Moch
Posts: 71
Joined: 2003-03-21 22:29

Post by Moch » 2003-04-30 01:41

There isn't any search expandability in search types right now except for how a client what a single byte means.... Client only sorting is not a very elegant solution. I feel (maybe not others) that instead of effort being put into the clients to solve this one search issue, effort should be put into the protocol to make it completly flexible and then the clients be modified to support the protocol change.

There has been talk about using regular expressions as search terms. If all clients supports the regexp matching then practically any search imaginable can be done. Clients could have any number of "custom" searches for filetypes, or file conditions (IE: mp3[1..4].mp3 would match mp31.mp3 mp32.mp3 mp33.mp3 and mp34.mp3). As long as the search is sent out to a proper client it would easily be able to send back the matches, even if this custom search isn't included with the responding client, because it would know how to handle regular expressions.

So... again, It would be nice to have the man power in changing the protocol to send regularexpressions rather than it being wasted on unelegant search 'rigging' to meet a quick need now.

~Moch

fbrandt
Posts: 1
Joined: 2003-05-01 03:48

Post by fbrandt » 2003-05-01 03:53

Just my 2 cents but can't we make this search filter user adjustable?
A tabsheet in options where we can add names and filter strings would be great in my opinion.

That way anyone can define what possibilities he wants in the filter.

Franky

Moch
Posts: 71
Joined: 2003-03-21 22:29

Post by Moch » 2003-05-01 12:34

The way the protocol works right now you already have the most flexibility you can with the current interface. If the CLIENT filtered results as they came in then something on the lines you are talking about can happen... but that is where you run into the waisted bandwidth problems.

What I mentinoned in my Previous post would allow what you just said. To have custom filters that you can send out as a regular expression so the clients would know how to respond.
~Moch

sarf
Posts: 382
Joined: 2003-01-24 05:43
Location: Sweden
Contact:

Post by sarf » 2003-05-01 14:37

Due to the number of search requests DC++ is supposed to keep up with, I do not think regexp-searches are a good idea. Unless they're kept strictly away from the $Search command and maybe uses a $SearchRegExp command, so that it is possible to deny searches if your available CPU time is too low (or rather, if you already have n regexp-searches going on).

Currently, DC++ works very well with regards to CPU-time - I'd hate to be forced to remove this feature myself due to 100% CPU usage.

That said, some sort of boolean logic should not be too hard to add (algorithmically speaking) and it would not eat too much CPU time, either.

Sarf
---
Only borrow from pessimists--they don't expect to be paid back.

Moch
Posts: 71
Joined: 2003-03-21 22:29

Post by Moch » 2003-05-01 18:58

You're right regexp's could get very... time consuming ;)

Yes, boolean logic wouldn't be to hard to implement... someone just has to code it's support.

Good points.
~Moch

sandos
Posts: 186
Joined: 2003-01-05 10:16
Contact:

Post by sandos » 2003-05-02 10:18

sarf wrote:Due to the number of search requests DC++ is supposed to keep up with, I do not think regexp-searches are a good idea. Unless they're kept strictly away from the $Search command and maybe uses a $SearchRegExp command, so that it is possible to deny searches if your available CPU time is too low (or rather, if you already have n regexp-searches going on).
I dont see why reg-exp searches couldnt be denied even if theyre using the same command.

Also: regular searches should also be deniable. DC++ should implement a search-queue, if it gets too big, drop requests. Then also run the search-thread on low prio.

sarf
Posts: 382
Joined: 2003-01-24 05:43
Location: Sweden
Contact:

Post by sarf » 2003-05-03 03:47

sandos wrote:I dont see why reg-exp searches couldnt be denied even if theyre using the same command.
Because currently search requests are non-deniable. This behaviour is implicit in the protocol, but more importantly are implemented with stupid bots on the hubs. No search results from certain search requests - too bad, then you must be using a leech client.
Unfortunately, I think it is "too late" to redefine the $Search command at this time.
sandos wrote:Also: regular searches should also be deniable. DC++ should implement a search-queue, if it gets too big, drop requests. Then also run the search-thread on low prio.
Well, I'd really like to see this, but this is one reason why I wanted $SearchRegExp - or perhaps $SearchExtended? Anyhow, it would give us a way out of the current situation by allowing us to implement search queueing and searching on low priority requests (both very good things!).

Sarf
---
If we humans are so smart and so creative, why aren't we happier than they are?

cologic
Programmer
Posts: 337
Joined: 2003-01-06 13:32
Contact:

Post by cologic » 2003-05-03 14:55

Because currently search requests are non-deniable. This behaviour is implicit in the protocol, but more importantly are implemented with stupid bots on the hubs. No search results from certain search requests - too bad, then you must be using a leech client.
Unfortunately, I think it is "too late" to redefine the $Search command at this time.
Well, those stupid hub bots don't use regexp searches, and if they so desired, they could certainly add $SearchRegex support as easily as a plain $Search variant that happens to use regexes; its being a separate command does nothing to redefine the semantics of how a client should respond to search queries. If

I agree that this expectation should be changed, but it's not necessary to define a new command to do it.

(Side note: if you _do_ define a new command, it would be nice for it to be more general, i.e. support various boolean conditions, metadata if necessary. Don't go and introduce a new search command just for regexes.)

sarf
Posts: 382
Joined: 2003-01-24 05:43
Location: Sweden
Contact:

Post by sarf » 2003-05-05 05:45

cologic wrote:Well, those stupid hub bots don't use regexp searches, and if they so desired, they could certainly add $SearchRegex support as easily as a plain $Search variant that happens to use regexes; its being a separate command does nothing to redefine the semantics of how a client should respond to search queries.
Maybe. If we create a new command, however, we can redefine what that command should do/return without making NM DC stop working.
cologic wrote:I agree that this expectation should be changed, but it's not necessary to define a new command to do it.
Sure, but I would feel better if there were a new command that defined some way of telling the requesting client what you want it to know, and not just a way of sending back search results.
cologic wrote:(Side note: if you _do_ define a new command, it would be nice for it to be more general, i.e. support various boolean conditions, metadata if necessary. Don't go and introduce a new search command just for regexes.)
Of course not! That's why I suggested the $SearchExtended (or whatever).
The only problem I have now is that the hubs do not support broadcasting of anything other than "$Search" and "<User> Blahblah" things... oh well, maybe we need to send a special type of search command. If we could rely on the hub we would get less problems since the hub could know what clients supported the $SearchExtended command... Oh well, just my dreams of a perfect world butting in on the conversation.

Sarf
---
I got out of bed for this?

Locked