RE: Log file rotation... log sub system

2002-03-02 Thread Sander van Zoest

On Sat, 2 Mar 2002, Ryan Bloom wrote:

> > > [EMAIL PROTECTED] wrote:
> > > Perhaps the logging module should be split up in the same way, with
> > > mod_log handling the hooks, and mod_log_disk handling logging direct
> to
> > > disk, mod_log_sql handling direct to database, etc.
> > Wouldn't just making ap_log_error() ap_run_log_error() solve a lot of
> > these problems?
> ap_log_error_core already runs a hook to allow module to do more with
> the error log, so this is effectively already done.

Do we maybe want to document these? It seems that half the time someone
asks a question on how to do something, it can already be done, but
there is no real way to know this unless you stare at the code every
day.

--
Sander van Zoest  [EMAIL PROTECTED]
San Diego, CA, US http://Sander.vanZoest.com/




RE: Log file rotation... log sub system

2002-03-02 Thread Ryan Bloom

> > [EMAIL PROTECTED] wrote:
> >
> > > Though I one 100% agree with the stance that a proper web server
> should..
> > > well.. serve pages - It sure would be nice if we could have a
logging
> > > subsystem in apache 2.1 or higher which took care of some of the
> harder
> > > things for us module/appserver developers when bouncing around
> > > logging data.
> >
> > In v2.0, mod_proxy, mod_cache, mod_ldap and mod_dav all support
"sub"
> > modules beneath them to perform specific tasks (eg mod_disk_cache
and
> > mod_mem_cache for mod_cache, etc).
> >
> > Perhaps the logging module should be split up in the same way, with
> > mod_log handling the hooks, and mod_log_disk handling logging direct
to
> > disk, mod_log_sql handling direct to database, etc.
> >
> > Each logging submodule could allow "drop through" the way mod_cache
does
> > - so if mod_log_sql cannot handle a log for any reason, through
config
> > or through failure, it could drop through to mod_log_disk and not
get
> > lost.
> 
> Wouldn't just making ap_log_error() ap_run_log_error() solve a lot of
> these problems?

ap_log_error_core already runs a hook to allow module to do more with
the error log, so this is effectively already done.

Ryan





Re: Log file rotation... log sub system

2002-03-02 Thread dirkx


On Sat, 2 Mar 2002, Bill Stoddard wrote:

> Wouldn't just making ap_log_error() ap_run_log_error() solve a lot of
> these problems?

+1 - with perhaps something like an 'always pass through'. I.e. even if an
module provides an 'OK' it continues just as a 'DECLINE' so that certain
major failures can be detected reliable enough - and shared among
constituents. Otherwise one gets the 'log' the 'logger' problem.

Or it may be that there is _core_ config directive which singles out one
or more modules as 'allowed' to claim the log_error() stream with an OK -
but have this right normaly reserved to core.

Dw




Re: Log file rotation... log sub system

2002-03-02 Thread Bill Stoddard

> [EMAIL PROTECTED] wrote:
> 
> > Though I one 100% agree with the stance that a proper web server should..
> > well.. serve pages - It sure would be nice if we could have a logging
> > subsystem in apache 2.1 or higher which took care of some of the harder
> > things for us module/appserver developers when bouncing around
> > logging data.
> 
> In v2.0, mod_proxy, mod_cache, mod_ldap and mod_dav all support "sub"
> modules beneath them to perform specific tasks (eg mod_disk_cache and
> mod_mem_cache for mod_cache, etc).
> 
> Perhaps the logging module should be split up in the same way, with
> mod_log handling the hooks, and mod_log_disk handling logging direct to
> disk, mod_log_sql handling direct to database, etc.
> 
> Each logging submodule could allow "drop through" the way mod_cache does
> - so if mod_log_sql cannot handle a log for any reason, through config
> or through failure, it could drop through to mod_log_disk and not get
> lost.

Wouldn't just making ap_log_error() ap_run_log_error() solve a lot of these problems?

Bill



Re: Log file rotation... log sub system

2002-03-02 Thread Graham Leggett

[EMAIL PROTECTED] wrote:

> Though I one 100% agree with the stance that a proper web server should..
> well.. serve pages - It sure would be nice if we could have a logging
> subsystem in apache 2.1 or higher which took care of some of the harder
> things for us module/appserver developers when bouncing around
> logging data.

In v2.0, mod_proxy, mod_cache, mod_ldap and mod_dav all support "sub"
modules beneath them to perform specific tasks (eg mod_disk_cache and
mod_mem_cache for mod_cache, etc).

Perhaps the logging module should be split up in the same way, with
mod_log handling the hooks, and mod_log_disk handling logging direct to
disk, mod_log_sql handling direct to database, etc.

Each logging submodule could allow "drop through" the way mod_cache does
- so if mod_log_sql cannot handle a log for any reason, through config
or through failure, it could drop through to mod_log_disk and not get
lost.

Regards,
Graham
-- 
-
[EMAIL PROTECTED]"There's a moon
over Bourbon Street
tonight..."


smime.p7s
Description: S/MIME Cryptographic Signature


Log file rotation... log sub system

2002-02-27 Thread dirkx


Though I one 100% agree with the stance that a proper web server should..
well.. serve pages - It sure would be nice if we could have a logging
subsystem in apache 2.1 or higher which took care of some of the harder
things for us module/appserver developers when bouncing around
logging data.

I.e. things like buffered logging, had some light transactional, or at the
least, reliable/agreed ordering in reasonably sided 'atom's and a few
things like that. Today it is too easy to garble a log.

And ideally it would still be 'stream's oriented with arbitrary sided
un-dividable granules in those streams; with the granules not too ascii
(but rather asn1 or so) oriented. As this would allow for some very
interested (and very vendor specific/product/database tailoered) things
build on top of that. .. just daydreaming. This is a -big- undertaking.

As an aside -Anyone seen this xml<->ans1 mapping. Truly cool and combines
the best of both worlds. See (http://www/itu.int/ITU-T/asn1/ or
http://asn1.elibel.tm.fr/en/xml/)

Dw.