anomy-list

Info on logging code

From: Bjarni R. Einarsson (19204@xyz.molar.is)
Date: Tue 28 Aug 2001 - 17:43:02 UTC

  • Next message: Hoang Chuong: "(no subject)"

    On 2001-08-28, 10:45:49 (-0500), Sterling Hanenkamp wrote:
    > Sorry, I misread the code. My interest is in the $attr variable not the
    > $level. Sorry for the extra mail.

    The new logging code is meant to create logs which are
    simultaniously machine and human readable. Thus the $tag and
    $attr are supposed to contain all info needed for machine
    analysis of the entry, but the $data field (the text field) a
    formatted string for humans. $level is used for reducing detail
    in output.

    The formatted $data string should always be completely static -
    any variations should be implemented by referencing entities in
    the $attr hash, so the message itself can be translated to other
    languages if/when I i18n-ify the Sanitizer.

    When encoded as XML the contents of the $attr hash are encoded as
    attributes for the tag.

    Example:

     $plog->entry("modifications", SLOG_INFO,
                              { base => $self->{"base_mod_id"},
                    end => $self->{"mod_id"},
                    total => $self->{"mod_id"}-$self->{"base_mod_id"} },
                  "Total modifications so far: %total%");

    Reduces to the text: Total modifications so far: N
    Reduces to XML: <modifications base="L" end="M" total="N">
                             Total modifications so far: %total%
                                              </modifications>

    The level (SLOG_INFO) is used for pruning out entries of a
    particular type - when embedding logs in messages it doesn't make
    sense to print a detailed program trace, but that's something
    very useful to have on disk (e.g. by printing to STDERR and
    saving) if the program does something stupid.

    Finally, it's possible to register hooks within the logging code,
    for crude event handling (each $tag represents an event). This
    will be used to reimplement the scoring mechanism in coming
    versions of the sanitizer, where the scoring code will check for
    certain tags and their attributes, and increment one or more
    score counters based on what's going on.

    I'd suggest you use this feature to reimplement your notification
    code - use event hooks to increment counters for the various
    events you want to notify people about, and then send a few
    composite messages after processing is finished - your old patch
    would send a person a message for each attachment dropped, which
    is irritating behavior at best when people send messaages with
    multiple attachments.

    Obviously, alot of the abstraction I'm doing now does little to
    improve the original stdin/stdout Sanitizer - I'm making life
    easier for people (myself) who are building more complete
    solutions. For example, today it should be relatively easy to
    write a sendmail-milter plugin, or a filtering POP or SMTP proxy
    using the sanitizer engine - things which would have been rather
    hard to do cleanly 3 or 4 versions ago.

    -- 
    Bjarni R. Einarsson                           PGP: 02764305, B7A3AB89
     19204@xyz.molar.is                -><-              http://bre.klaki.net/
    

    Check out my open-source email sanitizer: http://mailtools.anomy.net/



    hosted by molar.is