[Solved] Fully separating the Treasury API from platforms

[MrIvanPlays]

As I've started implementing BungeeCord platform I've discovered some problems.

First, events are handled differently in different platforms. Bukkit has a hierarchy of calling events e.g. in the Treasury Economy API we have AccountTransactionEvent, PlayerAccountTransactionEvent and NonPlayerAccountTransactionEvent. The PlayerAccountTransactionEvent and NonPlayerAccountTransactionEvent extend the AccountTransactionEvent, which would mean that if you call either PlayerAccountTransactionEvent or NonPlayerAccountTransactionEvent it would result in calling the AccountTransactionEvent.
BungeeCord does not have such hierarchy, that's why I wrote this utility for economy implementations in order for the events to act how Bukkit events act, which from my standpoint is a hack.
Another problem is that we aim for Treasury's methods to be asynchronous ; both Bukkit and BungeeCord support calling them asynchronously, but the difference is again huge - in Bukkit you have to specify by a boolean value that this event is asynchronous, whilst BungeeCord which is not situated around 1 thread - you can call them on any thread you want. Even bigger problem is if you want to run asynchronous tasks in an event listener. BungeeCord supports this using the AsyncEvent, but that implementation has been called out multiple times with race conditions and whatnot, whilst Bukkit has no support for that at all! There's no way on Bukkit to block event execution until an asynchronous task finishes!
The solution to this is to create our own event handler implementation. Not just for Treasury Economy API, but for Treasury API as a whole. I really like the approach Velocity took with events in Velocity 3.0.0, so in my opinion we should borrow the way they did it.

The other big problem is retrieving the provider interfaces. As of writing this, Treasury has only 1 API - the Treasury Economy API with its own EconomyProvider. For Bukkit it's easy - you throw in a registration in the service provider for that EconomyProvider and you're good to go. For other platforms such as BungeeCord/Velocity, there's no such thing as a "service provider". So I wrote this, which in my standpoint is bad. It can be improved hell lot.
The solution to not all implementations having a service provider is again, simple, write our own in Treasury API. But here's the con in my opinion - it has to be all static, because there's no other way for economy consumers to use that. The thing is that, per standards, static shall only be used for either a) utilities or b) registries. A service provider is none of these.

I want opinions on how should we proceed. Thanks for taking the time to read this :).

When we get to the point of "we should do that" I'm going to create an issue from this discussion tab and we will get to work :).

[lokka30]

We're treading into territory which will become very annoying for us to deal with.

I'm willing to let go of the prospect that is BungeeeCord support. Even Velocity, if developing Treasury for it proves to be too difficult, but obviously I am less bothered by dropping Bungee. This is because the overwhelming majority of what Treasury's APIs will be used for, will take place on servers (Bukkit/Sponge) and not proxies. There are few cases where Treasury would actually be useful on a proxy. This is of course my opinion and I could be completely wrong.

With Treasury I'm focusing my efforts on trying to make the economy API's usage more widespread, and later on I plan on adding Chat & Permissions APIs, still targeting Bukkit servers.
I don't believe porting the API, to platforms which make it difficult for us to do so, is something we should spend our efforts on just yet. However, anything that might need changing in the future to facilitate such new platform support, e.g. this service provider situation, we should try to solve these as soon as possible, with highest priority. I would much rather make any API changes now than later.

Now .. regarding the service provider situation on the proxies.
Unfortunately it looks like the warranted (at least from my perspective) 'abuse' of static methods to achieve a Bukkit-like service provider system is the best way to go. To my knowledge.
Or otherwise, if these proxies offer something like Bukkit.getPluginManager().getPlugin("Treasury") (grab the main class) to access our core, which could have methods handling the service provision. Perhaps that is another idea we can think about. This comes with the issue that plugins should not have to depend on Treasury's core to use the APIs.
There is no clear path to take so it will likely take a good amount of brainstorming to find a solution that is somewhat ideal enough to accomplish our goals.

I do not feel that the events code should be in the core at all, rather, platform-specific. If there are differences between platforms on how they handle events, 'so be it' I think. I don't want to write workarounds and hacks to get things working similar to Bukkit, even though such a result would be ideal.
If adding events to a platform means we must (as the only feasible option) develop a specialized EventHandler for them, then I think we may as well not even bother, unless there is decent demand for it.

What I feel we should do, is take a look at the limitations of each platform. Consider what we need to do to combat these, or if we have to sacrifice either some features e.g. events or even the entire support for the platform, then we need to discuss this too.

I was not expecting the events systems to be so different on these other platforms, I have never had any issues with Bukkit's design so it is quite frustrating to observe these differences.

[Jikoo]

IMO proxy support is important specifically because it taps a market that Vault does not. There are already a lot of database-based multi-server economies, but anyone trying to use those is required to write a Bukkit plugin that will interface with it on every single server. Theoretically someone could easily adapt Vault to Bungee, but afaik no one has.

Being able to seamlessly transition to that for future expansions like permissions is really great. I think most people just directly use the LP API if they want a cross-platform permissions API, it would be nice to open up more possibilities.

[MrNemo64]

Unfortunately it looks like the warranted (at least from my perspective) 'abuse' of static methods to achieve a Bukkit-like service provider system is the best way to go. To my knowledge.

Exactly what I meant in the initial post too. My ears are all open to other ideas of going with a service provider. Again, if you are concerned that such thing won't be maintainable or something, a service provider is literally 1 class.

If you think about it, it makes sense for a service provider system to be a singleton. If you have multiple service providers you'll have multiple services running for the same purpose at the same time

This comes with the issue that plugins should not have to depend on Treasury's core to use the APIs.

Exactly. API should be completely separate from the plugin part of Treasury.

Tecnically we could make the plugin class implement an interface defined on the API so when using the Bukkit.getPluginManager().getPlugin("Treasury") you can cast it to the interface. This option will also bring all the problems that you expect.
I'll so some thinking myself

[MrIvanPlays]

If you think about it, it makes sense for a service provider system to be a singleton. If you have multiple service providers you'll have multiple services running for the same purpose at the same time

I'm an absolute idiot. I completely forgot about singletons existing. We can make the service provider a singleton. HOW DIDN'T I THINK ABOUT THAT SOLUTION??? MrNemo you're 2000 IQ.

Tecnically we could make the plugin class implement an interface defined on the API so when using the Bukkit.getPluginManager().getPlugin("Treasury") you can cast it to the interface. This option will also bring all the problems that you expect.
I'll so some thinking myself

This is hacky and problematic. Going with the singleton is the best I can think of.

IMO proxy support is important specifically because it taps a market that Vault does not. There are already a lot of database-based multi-server economies, but anyone trying to use those is required to write a Bukkit plugin that will interface with it on every single server.

Completely agree with this.

Theoretically someone could easily adapt Vault to Bungee, but afaik no one has.

I tried at one point but failed miserably in doing so. Search for "com.github.mrivanplays:VaultBungee" in maven central and you will be able to see. That's why I came to Treasury, because I need a all-in-one API that works cross platform.

I think most people just directly use the LP API

AFAIK there is only 1 permissions plugin that works on bungeecord except LP that is kinda known. I forgot its name because I can't remember names :D . Anyways, opening up that market by making a unified API would mean more devs would start doing permissions plugins, possibly something amazing that can compete with LP.

[lokka30]

You might be thinking of BungeePermissions. LP has shadowed every other plugin so much I can't even remember if that's the right plugin name either! 😆

Very glad the service provider situation is sorted out! I thought that was going to be a headache.

And Jikoo, you're absolutely correct about the untapped potential there.

[MrIvanPlays]

You might be thinking of BungeePermissions

Yep it had Bungee in its name that's correct. Perhaps it was called like that.

[MrIvanPlays]

Current conclusion:

• Creating a event handler.
• Creating a service provider. Shall be singleton.

Code ideas wanted. What I'm thinking about the service provider is something like bukkit's but simplified. And for the event handler - something like velocity's but again kinda simplified.

I'm all ears.

[lokka30]

Using a similar design for both systems from those who do it best, sounds like a brilliant idea to me. I haven't looked into Velocity's event handler system before, are there many major differences we should know about?

[MrIvanPlays]

I am not going to implement anything like bukkit's or bungeecord's event systems. They suffer from a lot of problems. What I'm only going to borrow from bukkit is the event hierarchy. That's it. Everything else shall be inspired by velocity, but obviously not copied, because it's also not completely ideal and I don't like some design approaches they went for. But basically this is it:

@Subscribe
// getting a Continuation is optional
public void onServerConnected(ServerConnectedEvent event, Continuation continuation) {
  // this is not an actual method, this is just to demonstrate
  runAsync(() -> {
    // do something and modify the event
    // then you have to call continuation.resume() or if there's an error you can call it with 
    // continuation.resumeWithException(exc)
    continuation.resume();
  });
}

of course i am not going to deal with methods and reflections because that's gonna be slow for our needs. what we can have is something like the observer pattern or something borrowed from reactor e.g.

eventHandler.subscribeTo(AccountTransactionEvent.class).withListener((event, continuation) -> {
  // do stuff
});

[lokka30]

That second code snippet looks SWEET!