A few design questions

[Foxtrek64]

Hello!

I happened across this project while looking for C# implementations of Minecraft Server. I need to do some pretty unique things for my use case and trying to figure out how to make them work in Java/Kotlin and building against Forge has not been a fun time to say the least.

As a .NET developer myself, I was digging through your codebase to see what you were doing with it and ran across some interesting design decisions that are outside what I would have expected. I don't want to come in here and sound like I'm saying "this is wrong, change it for my sake!" Instead, I hope to gain an understanding the design decisions here in the hopes that I may learn something from outside of the Microsoft world and become a better programmer for it. Exposure to new ideas and patterns is one of the best ways to improve language skills, after all.

Firstly, things seem designed to be catered to existing Bukkit/Spigot developers. For instance, with your plugin library, you have a PluginAttribute which works almost exactly like the one found in the Spigot API. You also use an InjectAttribute on properties to inject dependencies, much in the same way as you would with Bukkit/Spigot. What was the decision behind going with this rather than going with something more traditional for C#? As an example of what I mean, the Remora.Plugins library is a good example of a small, lightweight library which behaves as more of what I would expect for something in the C# world (with the added benefit of getting rid of the necessity for reflecting class attributes).

Secondly, I noticed you rolled your own versions of classes like a ServiceProvider and a Logger. Any particular reason for doing this instead of working with the ones built in to the Microsoft.Extensions.DependencyInjection and Microsoft.Extensions.Logging namespaces, respectively? These tie in very nicely with GenericHosts (Microsoft.Extensions.Hosting) which is now the preferred way to handle long-running applications.

Thanks for your time and the opportunity to hear your thoughts!

Edit: Using a GenericHost would also resolve #102 since plugins would be able to define their own dependencies and provide them to the overall server's ServiceProvider. This would also allow for easy sharing between plugins, such as if one plugin acted as a library for other plugins as some do in the Spigot world.

[Seb-stian]

Hello! Thanks for the post and your valuable feedback.

I came up with PluginAttribute, InjectAttribute etc. with simplicity in mind, I don't have much experience with Bukkit/Spigot. I was thinking about moving to Microsoft.Extensions.*, but then some compile-time dependency injection libraries caught my eye and now I'm indecisive what to roll with. The whole thing is work in progress, so everything might end up differently.

I like the appeal of GenericHosts, they are very .NETy!

[Foxtrek64]

For the most part (it varies per library), I've found that a lot of libraries are designed to work on top of the Microsoft.Extensions.* libraries. As an example, I will often use Microsoft.Extensions.Logging with Serilog. Here's an example from one of my Discord bots:

.ConfigureLogging((context, builder) =>
{
    Serilog.Core.Logger seriLogger = new LoggerConfiguration()
        .MinimumLevel.Verbose()
        .MinimumLevel.Override("Microsoft", LogEventLevel.Warning)
        .MinimumLevel.Override("Major.DiscordSerilogAdapter", LogEventLevel.Information)
        .Enrich.FromLogContext()
        .WriteTo.Console()
        .WriteTo.RollingFile(Path.Combine(LogDir, "{Date}_Execution.log"))
        .WriteTo.DiscordSink(
            context.Configuration.GetValue<ulong>(nameof(ButlerConfig.LogWebhookId)), 
            context.Configuration.GetValue<string>(nameof(ButlerConfig.LogWebhookToken)))
        .CreateLogger();

    builder.AddSerilog(seriLogger);
    Log.Logger = seriLogger;
})

Afterwards, I can simply inject an ILogger<T> from M.E.L. into any of my services or plugins. Depending on what injection libraries you're looking at, they may well work alongside or on top of the Microsoft implementation. That may be worth looking into, regardless of whether you choose to use the additional libraries.

I'll go ahead and make an issue for the DI side. I'm curious to see what it'd take to implement, and it's probably a better place to discuss implementation details. This is definitely something I would be interested in contributing towards.

* I should point out, M.E.L. may be a poor example because it is not functional by itself. It requires a logging librar and requires a like serilog to function. This seems to be the odd man out though.