metlog.config.client_from_dict_config currently expects separate config and plugin_param dictionaries. The former contains most of the client configuration in dictionary format, while the latter contains a separate dictionary containing config info for the various extension plug-ins.
This works, but it complicates downstream code that depends on the client_from_dict_config API by requiring them to know about the possibility of there being a separate plugin_param argument. If we make sure that all necessary config info is always embedded within the single config dictionary, then new config features can be supported w/o any glue code needing to be aware of the changes, they'll just pass the single dictionary in as before. To this end, then, I'd rather see the plugin config dictionary stored inside the main config dict, as config['plugins'].
rafrombrc
commented
12 years ago
metlog.config.client_from_dict_config currently expects separate
configandplugin_paramdictionaries. The former contains most of the client configuration in dictionary format, while the latter contains a separate dictionary containing config info for the various extension plug-ins.This works, but it complicates downstream code that depends on the
client_from_dict_configAPI by requiring them to know about the possibility of there being a separateplugin_paramargument. If we make sure that all necessary config info is always embedded within the singleconfigdictionary, then new config features can be supported w/o any glue code needing to be aware of the changes, they'll just pass the single dictionary in as before. To this end, then, I'd rather see the plugin config dictionary stored inside the main config dict, asconfig['plugins'].