----- Original Message -----
> On Mon, 10 Sep 2012, Miloslav Trmac wrote:
> > 1) Consistency: Lumberjack is still very new, and fragmenting it now
> > weakens the utility of the specification.
>
> The Lumberjack spec is still flexible enough that I think we can make the
> case for the 'trusted' subobject there.
True.
> > 2) Namespace issues on input: The "pid" field has a specific purpose,
> > and applications can be expected to not store data in there; the
> > "trusted!pid" field is not specified, so it should be available for
> > applications to use. If imuxsock adds "trusted!pid", there will be > no
> > way to record both the value that was sent by the application and the
> > value added by imuxsock at the same time. On "output", we can solve the
> > namespace disagreements by using templates, but on "input", we don't
> > have a similar structure renaming mechanism (and I don't think we want
> > one either). Arguably this can be solved by using e.g. a "rsyslog!pid"
> > namespace, but that's fragmenting the specification even more.
>
> There are actually two PID fields, the field that the application writes
> as part of the syslog tag, and the field that is captured by the logging
> process via the 'trusted' mechanism. Not all logs are going to have the
> trusted tags, and it's better to be able to know which you are using.
Right, sorry about the sloppy thinking. It is still important to have a
"safe/reserved" place where to put the trusted values, but that doesn't mean
that rsyslog should use the same place for the trusted value as libumberlog
does for the untrusted one.
Mirek
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of
sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE
THAT.
