multicurrency, uuid and legacysupport

[anjoismysign]

It follows the principle of @LlmDl about using UUIDs as an option but not as a hard fork. It also provides a wrapper that can convert legacy providers (the ones that only make use of Economy and not IdentityEconomy). This is useful in case you wish to only listen to an IdentityEconomy and not have to make two layers for different economies... Take a look at the following as an example of what I am trying to explain... https://github.com/anjoismysign/BlobLib/commit/68116fbdd30d437f5e86c14584064d6492b8d89a

The wrappers also have built-in methods that will know how to register to Vault. This is because I have a pull request ready for Vault so that Vault detects when a legacy economy provider attempts to hook so it also provides an IdentityEconomy (if you don't understand why this, please start reading again).

I hope you don't heat up from this pull request. Most of IdentityEconomy was taken from the initial draft of @LlmDl. I don't have intentions to cause drama or discussion, I just want to finish this period of chaos... I believe that Vault (the original) is the way to go and follow! Again, sorry for all my previous mess...

[anjoismysign]

Also, solves #145

[GeorgeV220]

I believe Vault is abandoned, so probably a new fork with a different name like Vault2 or X should be made, idk to be honest.

[Geolykt]

I believe Vault is abandoned, so probably a new fork with a different name like Vault2 or X should be made, idk to be honest.

I mean the issue is that there isn't something that would force a change. And ABI breakages are pretty much a no-go with an application that is as ancient as Vault. So superficially, nothing changes.

A fork would make little sense - it would need to be a ground-up recode. There have been plenty of them in the past - but you only need to look around you to know what happened to them.

[GeorgeV220]

yes I understand, vault for better or worse has become an "industry standard" but I believe a good fork that is community based or a new implementation would be good. I don't know why the other vault forks didn't work but NuVotifier which is a better version of Votifier succeeded and has additional useful features.

[anjoismysign]

I agree. It seems that contributors lost interest in it... My proposal doesn't break current API, it only extends it. I also made a Vault2 (the JavaPlugin) which makes use of this pull request/proposal and provides new layers based on old/legacy classes. It's 100% possible to keep developing Vault & VaultAPI with new features without needing to deprecate software that already works!

[GeorgeV220]

I agree. It seems that contributors lost interest in it... My proposal doesn't break current API, it only extends it. I also made a Vault2 (the JavaPlugin) which makes use of this pull request/proposal and provides new layers based on old/legacy classes. It's 100% possible to keep developing Vault & VaultAPI with new features without needing to deprecate software that already works!

if someone is willing to do something like this and inform the community in relevant forums (Spigot, PaperMC, BuiltByBits and etc) I think it would have some impact. The plugin has remained more or less the same for many years and as minecraft evolves it has become somewhat outdated. It still works pretty well but we need new features like multicurrency, UUID support and even CompletableFutures if possible.

[Geolykt]

We need new features like multicurrency, UUID support and even CompletableFutures if possible.

No need to reinvent the wheel! APIs such as treasury already exist. But they all don't provide backwards compat with Vault for good reason. Implementing both worlds was very painful last time I tried.

[anjoismysign]

What? Didn't you read my pull request?

[Geolykt]

Your PR basically introduces several shadow economies that exist in parallel. Merging them into one singular economy is a tall order. I am very much of the opinion that it isn't possible to execute with 100% correctness due to the in retrospect unfortunate decision to attach everything to names.

Even then UUID & multi-currency support and everything else is optional. While that guarantees that ABI breakages aren't super common it also means that there is little reason to stick to the old Vault formula - API consumers can't just use the new UUID API willy-nilly - they'd need to check whether a plugin even exposes it, causing severe programming overhead. Hence most Vault "successors" only relegate compat with Vault to compatibility bridges. The idea there is: If breakages have to exist, then you can also get all other breakages in.

Converting all old databases from being name-based to UUID-based is another exercise that most wouldn't dare (remember that fake players are a thing).

[anjoismysign]

https://github.com/anjoismysign/Vault2 https://github.com/anjoismysign/BlobLib/blob/async-objectmanager/src/main/java/us/mytheria/bloblib/vault/multieconomy/ElasticEconomy.java

[GeorgeV220]

https://github.com/anjoismysign/Vault2 https://github.com/anjoismysign/BlobLib/blob/async-objectmanager/src/main/java/us/mytheria/bloblib/vault/multieconomy/ElasticEconomy.java

Enable the Issue tab on Vault2 and if it is possible make a new release :)

[anjoismysign]

https://github.com/anjoismysign/Vault2 https://github.com/anjoismysign/BlobLib/blob/async-objectmanager/src/main/java/us/mytheria/bloblib/vault/multieconomy/ElasticEconomy.java

Enable the Issue tab on Vault2 and if it is possible make a new release :)

Done