ideas fo eventlog in 3.0.21

[Gerald (Jerry) Carter]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Marcin,

I've been working on the eventlog code and finally doing
a full sweep of it.  I have an idea for a second generation
implementation of it.  Possible for 3.0.21.  Mostly, these
ideas come out of thinking about what it would take for
and end user to get the current eventlog features working.

It's always bothered me a little that there were so many
required eventlog scripts.  But I never could articulate why
it bothered me or provide and alternative for discussion.
I think now I can.

I would propose that we truncate the list to 2 parameters.

* eventlog list = <list of event log names>
* eventlog parsing command = <script>

The 'eventlog list' is just the same list of arbitrary
log names like we have now.

The 'eventlog parsing command' is passed a single argument
which is the name of the log.   This script works much like
the 'lpq command' in that it reads in the log file and returns
parsable output to smbd which can be cached in a tdb (one tdb
per log files).  We also keep a window of oldest and most
recent records.  So reading an eventlog is simply reading
records from a tdb.  Smbd itself is the daemon which handles
updating the log cache rather than requiring an external
process.

The actual log file attributes such as max log size, etc...
would be stored in registry.tdb.  The Log file caches would
only be caches (just like printing/*tdb).  The max log size
could be implemented by rounding off the size of a record
and just returning N * estimate_rec_size.

We could optionally add a clear log file command, but I
expect that just clearing the tdb is enough as long as
we maintain the last cache time so that the 'eventlog parsing
command' doesn't report old, removed records.


So for an admin to to export log files, she need only
write one script that generates a documented output
format rather than providing seven scripts.  And of course,
we can provide and example one that parsing standard
syslogd files.

So what do you think?  I know this is a little different than
how you have been approaching, but the best way for this code
to get adopted by the user community IMO is to lower the barrier
for entry.



cheers, jerry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDAqkiIR7qMdg1EfYRAl/JAKCRyPEYP2jfqdCyfkwjE+XtvJFYwQCgicgl
oL1tDrqJ+Yjkl9VfZngMG7w=
=vpxf
-----END PGP SIGNATURE-----