Developers of Sympa

[IKEDA Soji <address@concealed>]

On Mon, 05 Aug 2013 17:10:55 +0200
Guillaume Rousse <address@concealed> wrote:

> > - Unimplemented 'warn' level.
> >
> >    Developers' Howto
> >    http://www.sympa.org/dev/contributors/developers_howto
> >    tells about 'warn' log level.  It is not implemented.
> >
> >    I suppose 'warn' level might be useful for users, however,
> >    what is difference from 'err' level (especially from users' view)?
> Rather than yet-another-not-so-defined-log level, I'd rather reduce them 
> (for instance, merging debug, debug2 and debug3), and try to make a 
> better distinction between user-targeted runtime messages, and 
> developper-targeted debugging messages. User don't care about source 
> file, parameter values, or calling function, for instance, even in case 
> of error, they are just interested in "what did go wrong" information.
> 
> The current unique all-purpose do_log() function should probably 
> splitted in log_message() and log_trace_message() functions, the latter 
> being just a wrapper over the first one.

Two types of logging, one tracing/profiling and the other noticing,
looks good idea.

Former may correspond to current "debug*" levels.  I had been feeling
they might be enabled/disabled not accorindg to other levels.

On latter, I wish they would be controlled for convenience of users,
by something like "log_level" parameter.
Similar attempt is "log_module" and "log_condition", but I feel
they are slightly difficult to use for end users.

# Writing this, I found that the last question is related to this
# question.
# I imagined about such as Cacti's logging feature: it may be
# filtered by level, and users may get same information
# by syslog logs and Web-based logs.


> > - fatal_err() vs. croak().
> >
> >    fatal_err() seems to be replaced by croak() in most cases.
> >    Former requires Sympa module, while latter needs just a standard
> >    Carp module.
> >
> >    What are pros to use fatal_err()?
> It just predates usage of exceptions, and should better be dropped in 
> favor a exception handler in top-level code.

You proposed it before.  I have carefully thought on it for
a while, and personally concluded that it would not be adopted.

Perl5 does not have true exception handling such as
"try-except-finally-else" structure and "raise" statement (e.g. in
Python).  Behaviors of eval() and die() [or croak()] sometimes look
similar, however, they may be rather a Perl version of setjmp(3) and
longjmp(3).

To express exception handling by Perl5, code will be forced to be
slightly complex.  Though some CPAN modules have been proposed to
ease it, they often fail to implement perfect syntax for exception
handling.

So my conclusion is: We should not try to emulate exception handling
on Perl5, although I deeply feel how better Perl5 had supported it.

> > - Three types of logging.
> >
> >    Sympa::Log::Syslog::do_log(), Sympa::Log::Database::do_log() and
> >    wwsympa::web_db_log() are co-exist and they are not always used
> >    all at once.
> >
> >    Are separate logging functions needed for each logging store?
>  From what I understood so_far, Sympa::Log::Database isn't an 
> alternative for general purpose logging, but serves a distinct purpose. 
> I planned to rename the module as Sympa::PerfLogger, while splitting 
> Sympa::Log to Sympa::Log::Syslog and Sympa::Log::Stderr.
> 
> wwsympa::web_db_log() seems to be just a wrapper over Sympa::Log, 
> causing this last one to use a ugly 'if-im-called-from-web_db_log' 
> conditional block when trying to identify its caller.

Sure.  It is same as do_log() except that it includes global context
(robot, list, client IP, session) to the log.


Regards,

--- Soji


-- 
株式会社 コンバージョン  セキュリティ&OSSソリューション部   池田荘児
〒231-0004　神奈川県横浜市中区元浜町3-21-2 ヘリオス関内ビル7F
e-mail address@concealed  TEL 045-640-3550
http://www.conversion.co.jp/