RE: [logs] EventLog library

rgerhardsat_private

> > * character set?
> >   should we support different character sets? I think we 
> should but I'm not
> >   sure.
> 
> I think both are not required for the minimal/lowest common 
> denominator standard API, as they are part of the 
> "presentation layer".

We have done work with logging Japanese messages and we have learned
that it is not so easy to say "its just the upper layer". But I think
this should be postponed until we have something 1.0ish...

> 
> > * output modules character conversion
> >   should we use a single character encoding on the wire 
> (UTF8?) would it be
> >   mandatory or it should be configurable?
> 
> Just one. I prefer plain ASCII ;)

I opt for confgurable. ANSI does not work for double-byte character
sets. For example, in some encodings sare like this:

<ANSI-char><ANSI-char><ANSI-char><Lead-Byte><DBCS-Char><Trail-Byte><ANSI
-char><ANSI-char>

The Lead-Byte is typically a value above 128, the DBCS chars can than be
any value (including control-character like value like 0x0a or 0x0d),
the trail byte is again typiallxy above 128. I am just saying this to
level ground. As I wrote, I don't see any immediate need for action.
> 
> > * how to store the (prio, tagname) tuple?
> >   I assigned a priority to tags to support tag ordering. 
> This is done by
> >   using functions like this:
> >     evt_tag_str(e, 10, "testtag", "value")
> > 
> >   Currently I defined macros like this:
> >     #define EVT_TAG_TESTTAG     10, "testtag"
> > 
> >   which can be substituted in function calls like this:
> >     evt_tag_str(e, EVT_TAG_TESTTAG, "value")
> > 
> >   However I don't like this too much. Maybe a separate 
> struct to specify
> >   tags should be defined, but that would bloat the caller's code.
> 
> See above.
> 
> > * syslog facility/priority mapping?
> > 
> >   The syslog facility and priority values are currently 
> mandatory, they
> >   might be converted to simple tags, but how to send 
> messages which do not
> >   specify them?
> 
> I'd prefer it optional, so that the new API is not 
> permanently tied to syslog. Actually the same holds for the 
> second field of evt_open

Well - but if it is absent, an intelligent mapping to syslog might be
much more of an issue to map them onto syslog. We have build a similar
protocol for our interal use in the products and we decided to provide a
syslog pri/fac in any case. It doesn't hurt that much when developing
and greatly helps to keep things consistent. Also, admins are very used
to the pri/fac, so you might get an acceptance gain. I am not suggesting
an API extension right now as I am not sure how the rest of the group
feels about this... Comments anyone?
> > And finally:
> >   * applications, applications, applications
> > 
> > To help the final step, I'm going to convert syslog-ng to emit 
> > messages
> > using eventlog, and also schedule it into our Zorp project.
> 
> If we can get the common denominator we will have two 
> implementations, 
> which should be a nice start.

We'll implement it in our products (EventReporter, MonitorWare Agent,
WinSyslog) as soon as it evolves to relatively stable. So also support
on Win32. 
_______________________________________________
LogAnalysis mailing list
LogAnalysisat_private
http://lists.shmoo.com/mailman/listinfo/loganalysis