Integrating Pigeon.Configuration with Web/App.config? about akka.net

[rogeralsing]

There are a few options here I think.

1. We create a config section that contains a cdata element where we simply place the raw HOCON code.

2. Since HOCON supports substitutions. e.g. some.path = ${another.path.some.value}
   I guess we could make a provider that reads standard key/value pairs from app/web.config and injects those as values that can be used in substitution.

3. We create a config section where we simply place a file reference to a HOCON config file.

4. create a custom XML format for config. I really don't want to go down that route.
   The whole point of HOCON is to avoid XML/other non readable formats.

But some sort of relation to the app/web.config would be nice so that one can use the standard config transforms on build.

[Aaronontheweb]

My thoughts:

I'm with you on saying "no" to option 4 - that sounds like a bad experience for all parties involved.

IMHO, I think we can combine option 1 and 3 into a flexible system that would address 99% of use cases. Create a configuration section that has an optional configSource property - just like connectionStrings. If configSource is populated, then we'll look for the HOCON configuration in an external file.

If not, we'll treat the root Pigeon configuration element in App.config as a CDATA field and just parse the contents enclosed inside the tags.

How does that sound?

[rogeralsing]

Sounds fine with me.
Can this be done w/o including references to System.Web?
I mean if the config is stored on disc and we use a configSource, are we forced to use System.Web to resolve the path?

[Aaronontheweb]

Shouldn't need System.Web - just System.Configuration.Management. If we use a configSource inside web.config the path will be resolved relative to web.config and we can use configuration transformations to load different environmental settings, but none of that will require System.Web necessarily.

[rogeralsing]

Ok, do you want to take this one?

[Aaronontheweb]

Sure, let's do it - actively integrating it into an ASP.NET MVC application anyway; going to need it sooner rather than later.

[rogeralsing]

You might want to look into the .WithFallback feature of the config also.
This allows you to use multiple configs, if we ask for a config path; e.g. "akka.actor.something.foo", and that path is missing in the config, it will try to resolve this path using the fallback config.
This can also be chained multiple times.
This is how we combine the reference config with the user config.

Not sure if this is useful for the above feature, but technically, it is possible to combine configs.

[Aaronontheweb]

Wanted to add an update to this - I will be working on this soon. Almost have the V1 of our first Pigeon-enabled service finished. Immediately after it passes QA I'm going to be starting work on deployment procedures for it, which is where I will start work on this. Should have some progress made against this over the weekend.

[rogeralsing]

Awesome, just out of interest, how big is the user base for the service?

[Aaronontheweb]

User base for the service - we handle connections from anywhere to 250,000 - 500,000 devices per day and tend to do between 4-20 requests per device.

@rtumaykin and I need to do some more testing with remote actors this week, but once we have them working we'll be starting work on adding configuration section support.

[Aaronontheweb]

I've built an initial implementation of this - still getting some runtime errors with it (Microsoft has changed this API like a dozen times...); should have a PR in next week.

[rogeralsing]

Looking through the Java docs right now and ConfigurationFactory.Load() is the right place to initialize loading of the default config.

[Aaronontheweb]

@mmisztal1980 took care of this in his most recent PR. closing.