View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001873 | unreal | ircd | public | 2004-06-16 00:19 | 2013-05-20 18:40 |
| Reporter | Assigned To | ||||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | resolved | Resolution | no change required | ||
| Summary | 0001873: ELIST | ||||
| Description | ELIST=options Options: M = can search for a channel matching the given text N = can search for a channel NOT matching the given text (!) U = can search based on user count (>, <) T = can search based on topic setat time (T>, T<) C = can search based on creation time (C>, C<) Unreal supports MNU. TC was removed a while ago, I can't see why, the changes says it "fixed a bug" but no mention of what. So perhaps we can look into reimplementing these? Also, Unreal does something incorrect. For MN, Unreal applies the masks to channel names *AND* topics. Meaning if I do, /list *blah* it checks for #*blah* as well as a channel topic containing "blah." It should not apply to topics. Instead, I propose adding a new char where you can add masks for topic searching. Any suggestion on a char? (note: t can't be used since Bahamut decided to use lowercase for ELIST so it has to be case-insensitive) | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
Hm... well the /list *blah* thing certainly is wierd. mIRC seems to mutilate using /list with filters. For example, on my (currently private) server, I have 4 channels with the word "Dragons" in the topic - #Dragons, #Help, #Opers, #Auditorium (for playing with +u :) ). /list *Dragons* only returned 1 channel - #Dragons. However, /raw LIST *Dragons* returned all 4 channels as codemastr described. As for topic searching, deciding on a character does seem rather difficult. I can think maybe F (for Full name), seeing as T is already used, and O, P, or I just seems rather... strange (C is also taken). Though personally, I can't see the use of searching by topic set time. Also searching by C might be kinda... wierd if the services enforce the channel's registration time as the creation time :) . Though it'd be no different than searching with C on something like EFnet/IRCnet :) . |
|
|
Hmm, you're "full name" gave me a better idea. D (description). I agree, the topic time search and channel creation search probably aren't very useful, except in some extreme cases. Like I guess, it could be useful to find botnet channels. /list >100 C<5. If a channel was created in the last 5 mins, and already has 100 users, it's probably something bad going on... I'm sure if I spent enough time thinking of it, I could come up with some other reasons :P |
|
|
>Hmm, you're "full name" gave me a better idea. D (description). ROTFL ;) >I agree, the topic time search and channel creation search probably aren't >very useful, except in some extreme cases. Like I guess, it could be useful >to find botnet channels. /list >100 C<5. If a channel was created in the last >5 mins, and already has 100 users, it's probably something bad going on... >I'm sure if I spent enough time thinking of it, I could come up with some >other reasons :P Well, searching for botnet floods certainly do seem a good use of C. It's just T I have absolutely no idea what it would be used for (iow, can't think of anything off the top of my head). Maybe if you wanted to search for channels with topic updates within a certain time... I mean, who uses the Topic for just the topic? :P |
|
|
I can only think of one place that would be useful, and I don't think it actually exists anyway. Like if there were some kind of bot that did a /list to generate a list of channels for a website or something. Rather than do a full /list to get new topics, I guess they could do /list T>N where N is the number of mins ago that the list was last checked... Probably a bit of a stretch though :) |
|
|
>I can only think of one place that would be useful, and I don't think it >actually exists anyway. Like if there were some kind of bot that did a /list >to generate a list of channels for a website or something. Rather than do a >full /list to get new topics, I guess they could do /list T>N where N is the >number of mins ago that the list was last checked... Probably a bit of a >stretch though :) On that hand, perhaps a format for searching by the time of the last join/part/quit event? So that said bot would also only get a list with updated usercounts? Er... probably not a good idea (see below :p ) Though I can see problems with bots doing what you described. If a channel is destroyed (and not recreated) before the next scan, the bot will not see it in the list, and will think it was not changed, and will incorrectly show in the stats. So unless Unreal held the channel for a set time, and when the list is scanned again, it returns a null topic with a usercount of 0... but that's just stupid... get a smarter bot :P . |
|
|
MNUCT is now supported. I haven't added topic searching yet, because I'm not quite sure if/how I will do it. |
|
|
My first thought here is to possibly allow regular expression searching. I can't see it useful right away, and of course, there's those wierd dangers of malformed regexes making TRE go loopy... probably would want to stick with just wildcards until either TRE is more stable or something :) . |
|
|
Regex is definately NOT going to be supported. I'm not intending to make /list searching super complex. Wildcards are more than enough. If you want anything more, do it client-side. If we make tons of processing server-side, then the speed gained by not having to send a large list is lost by having to do heavy processing. |
|
|
Yeah, I have to agree with you on that... but the idea of filters is so that clients don't flood themselves out with insanely huge lists (which is possible even with SAFELIST) (coughefnetcough). Yeah, wildcarding should be enough. I'm curious though what format would be used for this. It looks like T and C use an operator as part of the syntax... I'm thinking LIST D=<matchtext> (maybe without the = ?) (and LIST D!<matchtext> to negate?)... what say ye? |
|
|
Dmatchtext D!matchtext That's what I was thinking, but there is a problem (the reason why I haven't done it yet). The options are comma seperated. Topics can include commas. If I did: /list Dfoo,bar in an attempt to search for "foo,bar" in the topic, I'd actually search for "foo" in the topic and "bar" in the channelname because it would see the , as a seperator. This means I'll need to either support escaping (Dfoo\,bar) or quoting (D"foo,bar") either way it will require some changes to the system because we use strtoken which simply reads up until the next token, it doesn't support quoting nor escaping. So I need to decide what I will do about that... |
|
|
There's a .NET trick that would sort this out... dunno if there's a way to do it in C... [C#] /* (I know my variable names suck, but hey...) */ string s = "Dfoo\,bar,*foo*,C<30"; string[] buffer = s.Replace("\\,", "\0").Split(','); for (int i = 0; i < buffer.Length; i++) buffer[i] = buffer[i].Replace("\0", ","); /* buffer[0] = Dfoo,bar * buffer[1] = *foo* * buffer[2] = C<30 */ [End C#] Yes, I know it's ugly. Using nullchar might not be the best way to do it (maybe CR or LF is better?), but that was the first character that came to my head that couldn't be sent by a user. That should catch \, but probably won't do what the user expects when \\, is used. Anyway, hope it's helpful ;) . *edit* I don't think strtoken will like null chars, so definately will want to use CR or LF. (Heck with that then you can get \\ to work right :P). */edit* edited on: 2004-06-21 18:35 |
|
|
Well, the thing is, C doesn't have any of those functions, so I'd have to write them all myself :P And if I have to do that, it's easier to just to write a strtoken that also supports escaping. |
|
|
Any chance anyone has any clue what the ELIST P character is for? mIRC mentions it in it's version log, but I can't find any IRCds that use it, nor any info on it. |
|
|
Haven't read any of this, but I suppose one of us could check all comments from above and see if there's still anything useful that may be put in 3.4.x |
|
|
nothing interesting here... at some point you're better off using an ALIS implementation anyway. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2004-06-16 00:19 |
|
New Issue | |
| 2004-06-16 17:18 | aquanight | Note Added: 0006651 | |
| 2004-06-16 17:48 |
|
Note Added: 0006653 | |
| 2004-06-17 01:41 | aquanight | Note Added: 0006667 | |
| 2004-06-17 12:53 |
|
Note Added: 0006669 | |
| 2004-06-18 13:01 |
|
Status | new => assigned |
| 2004-06-18 13:01 |
|
Assigned To | => codemastr |
| 2004-06-20 22:19 | aquanight | Note Added: 0006741 | |
| 2004-06-21 14:36 |
|
Note Added: 0006745 | |
| 2004-06-21 15:32 | aquanight | Note Added: 0006747 | |
| 2004-06-21 17:59 |
|
Note Added: 0006748 | |
| 2004-06-21 18:11 | aquanight | Note Added: 0006749 | |
| 2004-06-21 18:20 |
|
Note Added: 0006750 | |
| 2004-06-21 18:33 | aquanight | Note Added: 0006751 | |
| 2004-06-21 18:34 | aquanight | Note Edited: 0006751 | |
| 2004-06-21 18:35 | aquanight | Note Edited: 0006751 | |
| 2004-06-22 14:35 |
|
Note Added: 0006765 | |
| 2004-07-18 18:53 |
|
Note Added: 0007147 | |
| 2013-01-09 10:10 | syzop | Assigned To | codemastr => |
| 2013-01-09 10:10 | syzop | Status | assigned => feedback |
| 2013-01-09 10:12 | syzop | Note Added: 0017313 | |
| 2013-05-20 18:40 |
|
Note Added: 0017633 | |
| 2013-05-20 18:40 |
|
Status | feedback => resolved |
| 2013-05-20 18:40 |
|
Resolution | open => no change required |
| 2013-05-20 18:40 |
|
Assigned To | => nenolod |
