[Mailman-Developers] Adding keys in the configuration file

[Barry Warsaw]

On Sep 13, 2012, at 06:13 PM, Aurelien Bompard wrote:

>Yes, my idea was to have something like that in the mailman.cfg file :
>
>  [archiver.hyperkitty]
>  enabled: yes
>  class: hyperkitty.archiver.Archiver
>  base_url: http://archives.example.com
>  conf_file: /path/to/django/app/settings.py
>
>Only the conf_file key is invalid at the moment. It references the
>path to a Django settings file, but that's all.
>The Archiver class will then use this value to import the settings and
>go on with its job. That's the only place where there will be an
>import from the django namespace.

You could do it this way, but it would require HyperKitty to be colocated on
the same machine as the core, and that its settings.py file be importable by
the core.

Better IMHO would be for the core to issue an HTTP/REST+JSON style GET call on
some configurable URL to ask the Django server for the information.  Then
HyperKitty could reside anywhere.

>> Even if HK is enabled, django should not get imported into the MM space.
>
>I'm not sure I understand that. You mean in the same process memory ?
>Then I'm limited to some kind of client-server architecture, which I
>fear will have performance issues since we're passing every messages
>around. Or am I missing something ?

If you did it as a REST response, you'd want the HyperKitty IArchiver
implementation to cache the result for a while.  More savings would be
achieved if MM3 could calculate the archive url from a base url, a la our
extension to RFC 5064 I mentioned previously.

>I'm kinda lost here. I sort of understand that you're in favor of
>making the configuration file more extendable to fit the extension's
>needs, which would solve my problem. Mailman can't know in advance
>what kind of configuration values an extension needs, so in my opinion
>the conf file should either allow extensions to put arbitrary keys
>there (in sub-sub-sections for example), or let the admin specify the
>path to another configuration file, which would be extension-specific.

We do something like this already to implement password hashing via the third
party passlib package.  If you look at the [passwords]path configuration
variable, it names a url to an external passlib.cfg configuration file.  This
can use standard file: or http: urls, or as is shown in the default, a special
python: url scheme.  The semantics of python: url schemes is that the value
names a file in Python dotted-path name syntax for a file locatable on
sys.path (it doesn't need to be importable, but the parent must be).

I can certainly see something like this work for archiver configuration.

Cheers,
-Barry