This is only an idea, but maybe it's worth discussing. At the present moment we can see, that there are several libraries (by convention called Microsoft.Extensions.*.Abstractions), that are meant to provide a .NET Standard wide API for common things like caching, configuration, logging or dependency injection.

We already were loosely talking about potential to improve some parts of the Akka.NET API. I'm not talking about supporting all of them or none, but at least some of those would give us potential gain. Want to hear your thoughts @akkadotnet/core .

1. Abstracting HOCON configuration into objects

Most (all?) of the current akka extensions are already parsing HOCON config directly into object notation. The idea was to get rid of the direct HOCON dependencies in the internals, relying totally on objects instead.

This is place where Microsoft.Extensions.Configuration.* libraries would be handy: they provide common abstractions like IConfiguration, IConfigurationSource, ConfigurationPath etc. Moreover there are already implementations that automatically will allow us to parse i.e. Json, Xml or even Command Line arguments into that notation.

We'd need to do several things:

• Reimplement our XXXSettings.Create(Config hoconConfig) builders to XXXSetttings.Create(IConfiguration config).
• Expose ActorSystem.Settings.Config as IConfigurationRoot rather than HOCON Config object.
• Provide equivalent of Microsoft.Extensions.Configuration.Hocon library, that would keep backward compatibility with existing HOCON config. Outsource HOCON from akka itself.

Pros:

• Ability to integrate akka configuration with any existing solution i.e. Asp.NET appsettings.json or web.config.
• IDE support in place - right now HOCON is not supported by any .NET IDE. It's also dynamic: configuration cannot be verified and is often source of runtime errors.

2. Abstracting actor creation pipeline

As I've already proposed (#1675) and PRed (#2638) , we could replace current complex actor creation pipeline and abstract it together with dependency injection plugins. Some of the MS frameworks, like Orleans and ASP.NET Core, are already using Microsoft.Extensions.DependencyInjection.* libraries to provide a generic construction mechanism. We could adopt it on our side as well.

Pros:

• A common creation mechanism, that could be used to give native DI support for:
  • actors
  • serializers
  • event adapters
  • Akka extensions (no need to differentiate between IExtension and ExtensionIdProvider<>, as extension itself would be created via dependency injection). This is the most serious change, to be considered.
• No longer need to support and maintain hundreds of akka DI plugins.

3. Abstracting logging libraries

Microsoft.Extensions.Logging,* libaries give us primitives to abstract logging capability. This way we could outsource concrete implementations (NLog, log4net, Serilog) outside. However looking at nuget this is the most messy case of all.

Pros:

• No longer need to support and maintain logging akka plugins.