-----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 : [email protected]
> 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-----
<<attachment: stephane.vcf>>
_______________________________________________ Mailing list: https://launchpad.net/~openerp-expert-framework Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-expert-framework More help : https://help.launchpad.net/ListHelp
