openerp-expert-framework team mailing list archive

[Sharoon Thomas <sharoonthomas@xxxxxxxxxxxx>]

Good Idea!!
+1

On Mon, Feb 22, 2010 at 11:04 AM, Xavier Morel <xmo@xxxxxxxxxxx> 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<https://launchpad.net/%7Eopenerp-expert-framework>
> Post to     : openerp-expert-framework@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openerp-expert-framework<https://launchpad.net/%7Eopenerp-expert-framework>
> More help   : https://help.launchpad.net/ListHelp
>



-- 
Sharoon Thomas
Business Analyst & ERP Consultant
http://bit.ly/5FAJKU