Re: [repro-users] Repro Configuration

[Scott Godin <sgodin@xxxxxxxxxxxxxxx>]

Hi Francis,

Thanks you for the comments and the pointer to Poco.  Boost does have a configuration framework library called Program Options:  http://www.boost.org/doc/libs/1_47_0/doc/html/program_options.html.

However I opted to avoid bring in another 3rd party library at this point, since coding this stuff up, isn't that much work.

I should also explain that I am trying to move away from a configuration framework where every setting needs to be pre-defined (like in the CommandLineParser class today), and more towards a generic name/value pair approach.  An end goal is to make it as easy as possible to be able to add new Processors (ie. Monkey) to the chain.  Eventually I can imagine a plug-in type model for Processors, and I want the configuration framework to support this nicely.

Your point about being able to launch in a "one shot way" provides a compelling argument to keep command line options.  It will be relatively easy for me to allow setting of Name/Value pairs on the command line.  This won't be fully backwards compatible with the previous set of command line options, but it will allow you to continue to use command line options if it suits your needs.  (For example:  instead of -disable-registrar you would use --DisableRegistrar=true).

Thanks,

Scott

On Sun, Sep 11, 2011 at 8:45 PM, Francis Joanis <francis.joanis@xxxxxxxxx> wrote:

Hi,

I wonder if it would be possible to find a way to support both command
line options and configuration files through a transparent interface.

I know the Poco framework (http://pocoproject.org/docs/), through its
Poco::Util::Application class, supports a nice configuration API. It
automatically loads from .ini, .xml, ... files and also automatically
processes configuration items from the command line. The API itself
(through Poco::Util::Application::config()) makes the underlying
configuration store totally transparent (you can probably even extend
it to support mysql).

My main reason is that I find it extremely useful to be able to launch
applications like repro in a "one-shot" way from the command line.
This is quite useful when performing automated system tests (the test
manager can easily launch the components) or when "embedding" the app
(like repro) "within" another one where it is simply launched from an
execv/... call as an OS command.

I know bringing in a dependency on Poco would probably be a big deal
(and would conflict with rutil on multiple aspects), but I wonder if
there are other open source "configuration management" libraries
available out there (maybe boost has one?).

This would be more like a "nice to have" for me on the long run, so we
can always come back after your changes and implement it if others see
value.

Cheers,
Francis

On Sun, Sep 11, 2011 at 2:24 PM, Scott Godin <sgodin@xxxxxxxxxxxxxxx> wrote:
> Hi All,
> Repro currently get's its configuration from a combination of two locations:
> 1.  Command line options.
> 2.  Berkely DB or MySQL datastore.
> As repro has matured the command line options list has grown significantly.
>  I've heard feedback on a number of occasions that people in general prefer
> a configuration file as opposed to command line options.  A configuration
> file can be fully documented, and provides some persistence of settings
> between runs (without needing to create a startup script, or batch file).
>  I am in the process of converting the current command line options to be
> able to read from a configuration file instead.  I was originally
> considering an approach that would allow you to specify a setting using
> either method, however the further get along with this, the more I'm
> realizing that this will just increase the complexity  when adding new
> settings in the future.  Besides being backwards compatible with older repro
> releases, I am not seeing any major reasons to keep the command line options
> interface around.
> Users:  Would anyone be opposed to a complete deprecation of the command
> line option interface, given a configuration file interface as a
> replacement?  Note:  I've attached a sample configuration file to help you
> visualize how this would look.
> Developers:  I'm also going to cleanup how the settings are passed around to
> the various Processors (Monkey's, Lemur's and Baboons), so that modification
> of the Processor constructor isn't required every time a new setting is
> needed.  All these changes will make it much simpler to add new settings and
> use them, without needing to make modifications to 5 or 6 files.
> Scott

> _______________________________________________
> repro-users mailing list
> repro-users@xxxxxxxxxxxxxxx
> https://list.resiprocate.org/mailman/listinfo/repro-users
>