openerp-expert-framework team mailing list archive

[Stephane Wirtel <stephane@xxxxxxxxxxx>]

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

+1
Xavier Morel wrote:
> ----------------
> Rationale
> =========
> 
> All in all, the `netsvc.Logger` API is pretty pointless: it's verbose — extremely so when repeatedly using the same channel — it doesn't clearly use the hierarchical nature of the `logging` package and it doesn't fundamentally have any advantage over using `logging` raw. Its configurability is also very limited compared to the options `logging` provides.
> 
> Solution
> ========
> 
> But because it's built on top of `logging`, any configuration performed for `netsvc.Logger ` by OpenERP is actually performed for `logging`, which means it's possible to use `logging` right now without any issue: `logging.getLogger('foo').info('bar')` is completely equivalent to `netsvc.Logger().notifyChannel('foo', netsvc.LOG_INFO, 'bar')`.
> 
> Path of evolution
> =================
> 
> Phase 1 − 5.2
> -------------
> On calls to `netsvc.Logger().notifyChannel`, issue `PendingDeprecationWarning`. Because it's ignored by default, this won't change the behavior of the server unless using `-Wall`, `-Werror` or otherwise explicitly activating the display of PendingDeprecationWarning. Furthermore, even if activated as long as `-Werror` isn't used it will simply output a warning message to stderr (by default).
> 
> Strongly suggest that new logging be done via `logging` (by creating custom, hierarchical loggers), and that if existing logging code (trunk and addons alike) is touched `netsvc.Logger().notifyChannel` calls be replaced by the equivalent `logging` calls.
> 
> Phase 2 − next(5.2)
> -------------------
> Replace `PendingDeprecationWarning` by `DeprecationWarning`. `DeprecationWarning` is enabled by default (nb: except in Python 2.7, DeprecationWarning is now disabled by default unless using −3) which means it will appear to all developers unless explicitly silenced. As far as coding suggestions/standards go, same as phase 1.
> 
> Add a "regular" `logging` configuration to the current scheme (using `logging.config.fileConfig` to allow administrators and users to finely tune their logging via a logging config file, giving everybody full access to the `logging` API), optionally enable `logging`'s reconfiguration server (allows altering the logging configuration of a running system, useful to try to track issues without restarting the server as long as there is enough logging performed).
> 
> Mark the existing logging command-line switches (--log-level, --logfile, --syslog, --no-logrotate) as deprecated (issue `DeprecationWarning` when they're set), introduce a more standard set of log level switches (using multiple invocations of -q and -v switching between levels, with a default level of "WARNING" unless ortherwise configured in the logging file, `-vv` would be equvalent to `--log-level=debug`, `-qq` would be `--log-level=critical`).
> 
> Phase 3 - next(next(5.2))
> -------------------------
> Remove `netsvc.Logger` entirely, remove the existing python-based configuration scheme, replace it with an equivalent default logging.conf (logging can sequentially read several configuration files)
> 
> Remove logging configuration from the OpenERP configuration file (it moves entirely to "logging.conf"), remove the corresponding (deprecated) command-line switches entirely.
> 
> Future usage of logging
> =======================
> 
> Ideally, there should be far more logging than currently in OpenERP (and with the finer-grained logging.conf file & conf server it becomes possible to selectively silence specific loggers and logger hierarchies and dynamically reconfigure a server instance). Furthermore each object should have its own logger with the naming form {addon}.{object_name} (which means, among other things, that the `stock.move` methods redefined in `purchase` would log as `purchase.stock.move`, not `stock.stock.move`, potentially making debuggings and post-mortems much easier).
> 
> Documentary needs
> =================
> 
> The coding standard would need to be documented of course (where?), and a basic documentation for the creation of logging configuration files (as well as a way to send new configurations to a running server) should be created for phase 2 (the official `logging` configuration isn't bad per se, but it's a bit dense and aimed at Python programmers rather than e.g. system administrators).
> ----------------
> 
> So, what do you all think of this plan?
> 
> --
> Xavier Morel
> Developper
> OpenERP - Tiny SPRL
> _______________________________________________
> Mailing list: https://launchpad.net/~openerp-expert-framework
> Post to     : openerp-expert-framework@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openerp-expert-framework
> More help   : https://help.launchpad.net/ListHelp


- --
Stephane Wirtel - "As OpenERP is OpenSource, please feel free to contribute."
Technical Project Manager
Tiny SPRL
40, Chaussee de Namur
B-1367 Gerompont
* Tel: +32.81.81.37.00
* Web: http://www.openerp.com
* Planet: http://www.openerp.com/planet/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkuChsYACgkQnqh8s27uQNXJbwCfW4AmkEwTzBtyRIrrJUL6Y6Gu
dBMAoK13Hp2qs1DHpVaPTkNSOvVprO7Z
=Woah
-----END PGP SIGNATURE-----

begin:vcard
fn:Stephane Wirtel
n:Wirtel;Stephane
org:OpenERP - Tiny sprl
adr;quoted-printable;quoted-printable:;;Chauss=C3=A9e de Namur, 40;G=C3=A9rompont;;1367;Belgium
email;internet:stw@xxxxxxxxxxx
title:Developer
tel;work:+32.81.81.37.00
note;quoted-printable:OpenERP is an Open Source enterprise management software=0D=0A=
	=0D=0A=
	http://www.openerp.com
x-mozilla-html:FALSE
url:http://www.tiny.be
version:2.1
end:vcard