Custom config

[InRiPa]

I changed the constructor, so that it is possbile to use custom created config file. This is needed, when for example the server is running on another IP than 127.0.0.1

Adding following to a Users program utilizes that:

from arrowhead_client.system import ArrowheadSystem

my_config = {
        "service_registry": ArrowheadSystem(system_name='service_registry', address='192.192.192.192', port=8443, authentication_info=''),
        "orchestrator": ArrowheadSystem(system_name='orchestrator', address='192.192.192.192', port=8441, authentication_info=''),
        "eventhandler": ArrowheadSystem(system_name='eventhandler', address='192.192.192.192', port=8455, authentication_info=''),
        "gatekeeper": ArrowheadSystem(system_name='gatekeeper', address='192.192.192.192', port=8449, authentication_info=''),
        "gateway": ArrowheadSystem(system_name='gatekeeper', address='192.192.192.192', port=8453, authentication_info='')
    }

provider_app = ar.ArrowheadHttpClient(
        system_name='time_provider',
        address='127.0.0.1',
        port=7655,
        customConfig=my_config,
        keyfile='/path/to/certificates/time_provider.key',
        certfile='/path/to/certificates/time_provider.crt',
)

[... Additional code ...]

[ajoino]

Weird that the master branch has the eclipse licence but the development branch, good catch!

I think this is a good idea, but I think calling it config instead of customConfig is better, since any config you pass ought to be custom anyway. Also, customConfig breaks with the Python convention of using snake case for variable names.

Regarding configuration I've been toying with the idea (read implemented) locally the use of a global config variable. So instead of

config = {...}

ArrowheadClient(..., config=config, ...)

you'd just overwrite the default config with your own instead

import arrowhead_client.configuration

config = {...}
arrowhead_client.configuration.config = config

Or something like that, but I'm not sure at this moment, if you have any comments I'd be glad to hear them.

[InRiPa]

Hey, I understand your remark with the naming, and agree completely.

Regarding the usage of the config. In my opinion, the general use case would always be to provide a custom configuration for the new instance. In production, the default config won't be feasible most of the time (probably). Therefore, I think it makes sense to make it more or less mandatory for the creation of a new instance. Ultimately, the conf object can then be retrieved from an extra file like conf.json or stream. Like:

./
./libs
./conf.json
./myprovider.py

Suffice to say, please correct me if I didn't understood your second remark correctly :D

The main motivation behind this PR was to give the developer a way to change the core component endpoints. I couldn't find something to do it elsewhere. As mentioned here I'm trying to get a basic example running, which shows the library working. Maybe it would be sufficient, if there is at least one convenient way for the configuration for now and the idea for the best way of handling that can stay open for further thoughts?

Again, thanks a lot for your help on this :)