[collectd] Unify the filter_pcre and filter_ignore plugins

[Sebastian Harl]

Hi,

On Tue, Oct 28, 2008 at 11:12:50PM +0100, Florian Forster wrote:
> Only one `ignore' rule has to match for a value to be ignored.

I was going to optionally add that possibility to filter_pcre as well,
so you can either have a single match trigger the configured action or
require all regexes to match. The single match case would still differ
from the filter_ignore plugin though in that only one regex for each
component of the identifier may be specified within a single <RegEx>
block.

> I'm at a loss if the `TypeInstance' and `PluginInstance' options should
> be merged into the `Type' and `Plugin' options in the `filter_pcre'
> plugin. Thoughts, anyone?

Imho, they should be kept separate. One use-case for filter plugins is
to be able to rewrite "strange" plugin or type instances (e.g. some
weird sensor names or long interface names [as provided by Windows]).
Imho, the configuration would be much easier to write and read if one
may simply specify the appropriate *Instance option.

However, I'm looking at this from a developers point of view who knows
the internals fairly well. So, to a user it _might_ make more sense to
identify the instances the same way as found in the file-system, i.e.
using <*>-<*_instance>. It would be nice to get some feedback from users
on this topic.

> Also, would it be possible to fall back to ``normal'', i. e. enhanced
> POSIX regular expressions if `libpcre' isn't available? Then we could
> completely ditch the `filter_ignore' plugin, imho. Sebastian, what do
> you think?

Well, surely that would be possible ;-)

I'm not sure if that makes sense though. PCRE support quite a few more
features than ERE and users might end up with the same configuration
behaving differently on different hosts (e.g. failing on one while
working on another).

Also, I'm not sure if we would benefit from a code point of view. The
interfaces of regex(3) and PCRE are different, so we'd have to provide
some kind of abstraction layer and we'd have to dynamically load libpcre
at runtime (dlopen) to be able to handle the case when it's not
available.

Cheers,
Sebastian

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety.         -- Benjamin Franklin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mailman.verplant.org/pipermail/collectd/attachments/20081030/0669cf43/attachment.pgp