Add proper daemon configuration mechanism

[davidchappelle]

When the daemon was initially written there were very few options to support and it was serving more as a test harness or proof of concept rather than something that would be actually deployed. In order to build out bonefish into a more feature rich application router it needs to have a proper configuration mechanism. This mechanism would allow for any number of routers to be configured along with their associated realms and transports. Before doing any work here we will first need to re-evaluate the internal relationships between routers, realms and transports to make sure that the configuration is correctly modelled.

[jpetso]

Mind that boost::program_options, which the daemon is already using, also offers configuration through .ini files. I think that's probably preferable over a JSON format.

[davidchappelle]

Not sure that ini would be a very good approach. It would need to support nesting of sections which it doesn't appear to. Looks like ini is most useful for simple flat configurations. We need something that can support things like this (example borrowed from crossbar.io):

{
    "controller": {
    },
    "workers": [
        {
            "type": "router",
            "options": {
                ...
            },
            "realms": [
                {
                    "name": "realm1",
                    "roles": [
                        {
                            "name": "anonymous",
                           "permissions": [
                               {
                                   "uri": "*",
                                   "publish": true,
                                   "subscribe": true,
                                   "call": true,
                                   "register": true
                               }
                           ]
                       }
                   ]
                }
            ],
            "transports": [
                {
                }
            ]
        }
    ]
}

[ecorm]

You're already using RapidJSON to parse JSON into a MsgPack object tree. Why not use that?

Also check out Boost.PropertyTree which can parse JSON files.

[jpetso]

If we're using JSON then reusing RapidJSON would seem like a good candidate for implementing that. However, I still have reservations:

• JSON doesn't allow comments, which can be useful in configuration files
• JSON syntax is very strict, and you have to put quotes everywhere.
• I'm not a big fan of the fact that the very first level of options is already indented because I have to wrap it in a JSON object.

While the program_options parser doesn't seem to support "nesting" as such, it does support "sections" with dot delimiters:

[controller]
# no settings here apparently

[workers.1]
type=router

[workers.1.options]
# ...

[workers.1.realms.realm1.roles.anonymous]
uri=*
publish=true
subscribe=true
call=true
register=true

[workers.1.transports]
# empty too? can probably be omitted

[jpetso]

I would like to add that this is half as long and a lot more readable than the JSON equivalent.

[davidchappelle]

I am not 100% certain but I think iterating over sections becomes difficult and potentially very awkward. Plus program_options is somewhat rigid in terms of the set of options that you supply it with for parsing the ini file. You basically need a set of rules for each section based on the section name which must be predetermined ahead of time:

i.e. The options_description argument

http://www.boost.org/doc/libs/1_57_0/doc/html/boost/program_options/parse_config_f_idp49149232.html

I am not saying that it isn't possible but it might be a messy approach.

On Thu, Sep 10, 2015 at 2:09 PM, Jakob Petsovits notifications@github.com wrote:

I would like to add that this is half as long and a lot more readable than the JSON equivalent.

— Reply to this email directly or view it on GitHub https://github.com/tplgy/bonefish/issues/13#issuecomment-139330569.

[KrishnaPG]

Wondering if this is already implemented. If not, it would be great if compatibility is kept with the crossbar ones (as much possible at least in the initial stages), so that anyone transiting can find it easy to port the config files.

As for json vs other format, creating a simple json editor is pretty easy as web-ui (https://github.com/jdorn/json-editor). That should appease new-comers also.

Perhaps a static route dedicated / restricted to admins for editing the config files (over web) and hot-reloading them in the deamon would be the best choice for production environments (e.g. ws://localhost:8090/config)

• It also resolves the concerns of json syntax (comments etc.), and
• makes it easy to radically shift the schema in the future if there be a need.