Add API and Implementation for a Name to UUID Cache.#13
Conversation
|
I don't like the usage of events, could we please use interfaces? |
|
And how would you like to access those interfaces? |
|
Server.setUUIDLookup(UUIDLookup lookup) I think interfaces are more appropriate for this than events. |
|
Ok i will implement something more generic since i have multiple caches which i will implement in PaperSpigot to a later point but i understand what you mean |
| + * @param name of the player in any case (like given into {@link org.bukkit.inventory.meta.SkullMeta#setOwner(String)}) | ||
| + * @return the resolved uuid or null if the cache does not recognize this name | ||
| + */ | ||
| + UUID resolve( String name ); |
There was a problem hiding this comment.
An associated String resolveName(UUID) method would be nice (and rename this to resolveId).
There was a problem hiding this comment.
The use of the interface is internally and the only case i know is a Name => UUID resolve. A UUID => Name resolve would be nice for a open API like OfflinePlayer.getName()
|
@geNAZt |
|
Sure. So this PR is closed until the new open API is developed and i can plug that into the UserCache? |
|
I have not been following this closely enough to know what the status is. Are we wanting to do this, redo for some sort of backend, etc? Please advise. |
|
@Zbob750 |
|
Still a tad confused on the status but it seems that the consensus is "close this we'll work for something better". So I'll go ahead and close this, if that's not the case kick and scream for a minute and I'll re-open. Thanks for your time. |
Turns out Java 9 is still borked btw, I tested it wrong, whoops
4 participants
Some bigger Networks have the problem of hitting the Mojang API Limit with multiple instances at once. The solution was to implement some sort of HTTP Proxy which always has been a pain. This implementation can use caching of any sort.