ChatZilla:Message Filter

ChatZilla > Message Filter

Aims

• Allow the user to specify exactly where any message should go, by use of a system based on filters, similar to mail/news.
• Make a default set of filters to mimic current behaviour. Keep this around in order to be able to switch back to it. You don't want users to mess stuff up and find themselves unable to return to a normally working state.
• Allow filters to specify whether the system should continue to look into other filters that may match.
• Save the filters using Silver's system for javascript object storage.

A more technical draft can be found here: ChatZilla:Message Filter:Implementation Details.

Filter properties

Each filter has rules and actions associated with them. The actions will be executed when all the rules match the message. When there are no rules, the filter always matches. Apart from rules and actions, there are a few flags that can be set on filters:

• Stop processing. This means that if this filter matches, all its actions will be carried out, and then filter processing will stop (meaning, it will not try and use any of the filters after this one).
• Create tabs if necessary. This means that if this filter has an action specified to set a tab to a specific state, or display something on a tab, that the tab that this would happen on will get created if it isn't there yet. If this flag is not specified, the display or set tab state action will go down the list of tabs it gets, and set a tab state or display something on the first tab that does exist. If none of the specified tabs exist, no action will take place.
• Match all rules vs. Match any rule. Whether or not one rule matching is enough for the filter to match.

Filter rules

The user should be given an option to have all rules match, or just one (AND/OR difference) The filter rule system should be based on 4 fields:

1. The Type of the rule (see below)
2. The type of match done. This can be any of:
   • An exact match. This is easiest.
   • Starts with. Slightly harder, but still easy compared to others.
   • Ends with. Slightly unusual, but should be easy to do when the previous type is supported, and besides, don't kill people who don't understand regular expressions!
   • Contains. Simple, and expected by normal users
   • Regular Expression. Expected by power users.
   • Function match. Used by the client itself and obviously also by plugins/scripts.
3. The text or regular expression we're matching to.
4. Optional negation field. Easier than adding 'Does not' entries for everything mentioned in field 2.

Types of rules

What you can possibly match:

• Source Network name.
• Target channelname.
• Target username (you, but remember that you can have various nicks! You could use this, for example, to make a 'beep' when people use your name, *except* when it contains "sleep". Nifty, eh?)
• Source username
• Message contents
• Message types (INFO, JOIN, PART, QUIT, etc., and we need a way to get nice names for all those stupid response codes (end of list, whatever))
• Current away message.
• Use a function to match based on all available data.

Filter Actions

Somewhat surprisingly, we probably want 3 fields on 'what to do now'. So, suppose we matched a filter. What can the user tell us to do from the first field?

• Replace text within the message
• Display on:
  • the target tab (passed in by the caller, usually server / channel / user)
  • the source tab (for example, the user who sent the message)
  • the current tab. (whatever's current when display is called)
  • the handling tab. (the tab display was called on)
  • the parent of the handling tab. This is the network/server tab for users/channels/dcc, and the client tab for networks/servers.
  • the client tab. Plain, simple.
• Get Attention. Will flash the window. Ignores other fields.
• Set the tab state. Will use the other field to pick a state for this, and a list of views to try and set (same options as the display action).
• Play sound. Takes the second field into account: beep or url to sound file
• Dispatch. Takes the second field as the parameter.
• Run function.

Existing things that could be done using filters

• The stalk list
• Sound preferences (when to play sound)
• ? (I'm fairly sure there are more, but can't think of any at 7.16 in the morning. This is a wiki, feel free to add them.)

The question is, what do we want to do with those existing things? Can we/Should we dynamically move them to some filter? Create a filter based on the lists/preferences? Opinions please! :-)

--Eyalroz 07:30, 2 Jan 2006 (PST) says: Don't forget proper documentation and structuring of this filter system so that other people can write fixes for dependent bugs if necessary.

GijsKruitbosch 06:45, 7 Jan 2006 (PST) says: The current idea is that I write a documentation/spec kind of thing first (what should happen where, why, what should it do) and then actually code it. Coding it without thinking about what happens where is not going to go anywhere. So that should take care of this (although of course, I/we am/are likely to encounter problems when actually doing the coding)