RE: [logs] Syslog payload format

From: Rainer Gerhards (rgerhardsat_private)
Date: Fri Jan 03 2003 - 08:08:43 PST

  • Next message: Rainer Gerhards: "RE: [logs] Syslog payload format"

    > More important would be IMO to design the new API in a way
    > that it is possible to map it to "classic syslog" using 
    > simple C macros. If we can do this it would be possible to 
    > use the new API in e.g. open source projects regardless of 
    > the availability of the new logging subsystem. The usual 
    > (auto-)configuration step would then have to find out at 
    > compile time which logging subsystem is available. The 
    > "syslog mapping" should get at least that much information 
    > into the logs as the current syslog calls.
    Yes, agree on this. Even a simple wrapper that just takes the old style
    message and flags it as "old style" is helpful in my point of view. So
    we have the information that we are NOT dealing with the new type of
    > > [..]
    > > Wanting to be as close to syslog as possible is a nice 
    > thought but I 
    > > believe it's a dangerous one - the syslog API has so many 
    > things wrong 
    > > with it that being compatible or even close to it will inevitably 
    > > bring problems or impede progress.
    > Right, but I think we should look for a way to make 
    > transition to a new system as painless as possible.
    I strongly believe we should - at least in the beginning - provide a
    syslog(3) replacement that just does as I have written above. So a
    simple re-link is necessary. Maybe we can even get this into glibc over
    time... With a minimalistic replacement, there should not be much memory
    or other footprint be added to the existing apps. And the replacement
    could also check an environment variable (or /etc file or whatever) to
    dynamically determine if it should apply the wrapper formatting or true
    old-style format.
    > Sounds good. One thing to keep in mind is to clearly identify 
    > "free form" tags so we don't run into a situation where a 
    > revision of the tag dictionary adds tags that are already in 
    > use by some application.
    I suggest the old-style interface should always provide free form. A
    simple addition can then allow to explicitely flag it from a pool of
    agreed-on tags.
    LogAnalysis mailing list

    This archive was generated by hypermail 2b30 : Fri Jan 03 2003 - 18:57:53 PST