On Jun 8, 2009, at 2:34 PM, Ian Bicking wrote:
...
> You can put configuration in [DEFAULT] which will populate the
> global_config parameter to the entry points. But it would then be
> up to each application or middleware to look for information in that
> section.
That doesn't make much sense to me if the configuration is process
wide. Do you expect the "main" application to handle process-wide
configuration?
...
> For the specific case of logging, you can include logging
> configuration in an ini file (for example: http://bitbucket.org/bbangert/pylons/src/tip/pylons/templates/default_project/development.ini_tmpl)
Ah, so the configuration file is *also* passed to logging.fileConfig.
The logging.fileConfig syntax is rather bad. The implementation of it
is really horrible. I tried using it for a while and gave up. I'd
much rather use ZConfigs, as I did in my example.
> But this is setup specially in paster serve, and totally unrelated
> to any other configuration technique. Your technique would be much
> more general. But I'm not sure where else it would be applicable?
It would be applicable for any configuration that applies to the
process as a whole. Things like check interval, and other global
Python (or other settings). I might use it to load a ZCML file.
> Logging seems like a fairly unusual case where the module was
> designed for global configuration in this style. Another example
> where you'd want this kind of configuration is for an SMTP server.
> But you can't configure smtplib.
But there are higher-level facilities built on it that you can
configure.
> You could set up some new email package which accepted process-wide
> configuration, but that's not going to be a widely-used way of
> sending email, so it's not much better than taking the information
> in global_config (and global_config is slightly more scoped, it's
> more like inherited configuration, so it has a small advantage that
> you could support multiple configurations in the same process). For
> SMTP servers [DEFAULT] actually works okay, because everyone can
> mostly agree on the names of the parameters and how they are used
> (smtp_server, smtp_username, smtp_password, smtp_use_tls).
Where you put the information is only part of the problem. You also
want to be able call configuration handlers that act on the
configuration.
> I *would* like if there was a general way to configure something
> like Zope utilities -- dynamically scoped providers of
> functionality, that with an implementation and configuration. But
> that's a different kind of technique than what you are proposing here.
I would use this to load a ZCML file to define global utilities.
Jim
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Paste Users" group.
To post to this group, send email to paste-users@???
To unsubscribe from this group, send email to paste-users+unsubscribe@???
For more options, visit this group at
http://groups.google.com/group/paste-users?hl=en
-~----------~----~----~----~------~----~------~--~---
