State of the Treasury Project

[lokka30]

Discussion: State of Treasury

I wish to discuss, with anyone who is interested, the current state of Treasury. I have added my own perspective below.

---

My perspective

Note that I have omitted our current successes from this post just to narrow down on how we can improve. :)

I have also not proofread this post so please let me know if there's anything you're confused about.

Mistakes

The fact that Treasury was released to the public with version '1', implying a stable release, is what I believe an Achilles' heel which will choke the library's potential to evolve during its infancy. The moment Treasury was adopted first adopted into projects such as BetterEconomy created a realisation that we made mistakes during the development of the economy API. As the director of the project I take full responsibility for the actions I approve. I decided that an API version feature would be nice to have, that turned out to be a bad idea we quickly reversed. I decided that the subscription model would be easier for newbies to adopt, it turned out to be harder as it forced developers to use a ton of boilerplate, or convert every single subscription into a CompletableFuture which also forced pointless boilerplate (albeit, to a lesser extent than using subscriptions). I decided that the 'optional feature' system would allow newbies to implement features which are strictly necessary, though this turned to be a bad idea which we will reverse in the next major update. All three aforementioned issues cannot be resolved in a manner which is suitable for a library which advertises itself as being in 'version 1' - this leads back to where I describe 'version 1' as the Achilles' heel of the Treasury project. This leads into my thoughts on Treasury v2:

Treasury v2

This is going to hurt. We have to break current Treasury API implementations with a version 2 update so we can move on with working on what the library really needs. Either we deal with our unsatisfactory current standard and loose motivation to work on the project, or we break it and hopefully gain a better outcome. Remember, developers peek at an project once and don't like it: the grudge stays for 5 years, refusing to check again until someone encourages them to take another look.

Ivan has done a tremendous job working on the futures conversion, and also the subscription chaining idea. I also wish to implement new APIs into Treasury with this update - namely Permissions and Chat, the former of which I hope to discuss with Luck (of LuckPerms). I'm thinking Regions and other smaller ideas can come later as Vault feature parity is my current objective for Treasury.

To prevent repeating the same mistake, this version needs to be adopted in a beta stage and deal with breakages until we are fully satisfied with it. We're not going to expect it to be perfect when we are ready to release it and then see what happens in the real world.

Implementations (there lack of)

Lack of adoption

In the early stages of Treasury (which we are still in), we must be proactive in advertising and aiding to achieve greater implementation of the library. Otherwise it will be left in the dust. I wish to start out with Towny (since llamadeal approves), and perhaps even check if the EssentialsX team is on board. Hopefully this encourages other developers to reactively incorporate our APIs.

Under-utilization

I wish to add that the way we implemented transaction events may have been a mistake. We expected that economy provider implementers would adopt transaction events as our documentation requests, however, I don't recall any of the current economy provider implementations firing transaction events. Unfortunately, Java makes it tricky for us to solve this, though it is possible, sacrificing readability of the code, by using (if I recall correctly) the temple pattern, which yannicklamprecht suggested previously (though refused as we believed the "suggested" style would work).
The transactions feature has also been neglected. I find it is a brilliant idea since it can potentially aid in rescuing an economy which succumbs to an exploit of some sort - just roll back the affected data, and other players will be completely unaffected. I believe it just hasn't been implemented out of laziness and/or the lack of examples to implement it have caused it to be ignored (despite being a 'required' feature in the API).
However, I don't believe it should be our responsibility to handle or police how implementations utilise our API. If an implementation is incomplete, don't use it or suffer instability. That's my thinking. I think Treasury is fine in this case, apart from the documentation front.

My Economy Plugin

I plan to write an economy plugin that will take full advantage of Treasury and Vault's economy APIs. I hope that it will be able to serve as an exemplar of what Treasury makes possible and potentially source new Treasury adopters (both users and developers). Before I write this plugin, the issues I outlined above must be solved.

Example Implementation

I still believe that an example implementation will help developers be comfortable with adopting Treasury's APIs so they can see how everything fits together in their plugin.

To satisfy all APIs in one go, whilst keeping things dead simple, I believe a 'claim the chunk at x:0, y:0' example plugin (not suitable for actual use) will tick boxes. Use the upcoming regions API to state that block placement is not allowed, economy API so the player has to pay a transfer fee and taxes, permissions API so they require a permission, chat API to change their suffix if they own the chunk. Many possibilities :)

---

Tagging users who may be interested - let me know to opt-out: @MrIvanPlays @Jikoo @MrNemo64

[MrIvanPlays]

Agreed. I will be able to do stuff in september.