Matt Sergeant wrote:
> If we want logging to be parse-able by anything, the perhaps we should
> consider the option of outputting key/value pairs, probably separated by
> equals signs.
>
> That's kind of horrible for anyone adding in ad-hoc debugging though. :-/
Actually, I kind of see where having a parseable log line might be acceptable
for certain log lines. Imagine it this way:
1) any plugin calling $self->log() gets printed the way we currently display log
lines, i.e. just join(" ", @log).
2) The log lines emitted by the logging plugin itself (i.e. in hook_deny or
hook_reset_transaction) could have a completely different format (one that is
parseable).
The reason this would be OK is that all /ad hoc/ logging shows up as #1, so no
change. The lines emitted in #2 are special, in that they contain additional
context of being at a known terminal state of the transaction, and are more
useful to keep longer term logs.
I can see where Robin is going and I think it is one possible way to deal with
it. However, I don't think this particular scheme should be implemented as part
of the core logging/adaptive plugin, though I don't see any reason why it
couldn't be included in the core as a different logging plugin, say
logging/parseable. I would suggest implementing it as an isa_plugin() instead
of duplicating all of the existing logic.
John
