Velocity
Velocity copied to clipboard
PaperMC
Added initial framework for service API
This commit adds a barebones Service API to allow a discussion based solely on the framework itself before any service interfaces are created.
Resolves #231
Key notes:
- Currently services can only be provided by 1 plugin at a time. Bukkit allows services to be registered with priority. This may be something we should look into, but for the time being 1:1 is what is implemented.
- This is by no means aimed to be a finished product.
- This is loosely based on what Bukkit has implemented currently such that any interface can be registered by any plugin.
- Currently, services cannot be unregistered by either the proxy or any plugins
- There is very little by way of querying the registered services
I'm fond of the ability to create services, But I feel in order for this to be implemented we may need to be able to unregister the services. Along with that maybe some basic services like Permissions, User, and Eco. I can look into making a pr to implement these services if needed.
That's planned, but with that comes with trying to figure out where within the proxy we need to unregister which I was not ready to dive into. Since it's not crucial at this point, I PRed without
with that comes with trying to figure out where within the proxy we need to unregister
Out of curiosity, why would the proxy need to be able to unregister a service? In its current form, the PR doesn't allow the proxy to register a service (only plugins can), so it would only be able to unregister services that were registered by plugins.
with that comes with trying to figure out where within the proxy we need to unregister
Out of curiosity, why would the proxy need to be able to unregister a service? In its current form, the PR doesn't allow the proxy to register a service (only plugins can), so it would only be able to unregister services that were registered by plugins.
I'm not entirely sure that it would need to, but that discussion needs to be had. Which is why it was left out for now
We also need to decide the best way to store a plugin -> services map since there's no way to get that information without stepping through the services map
plugin -> services map since there's no way to get that information without stepping through the services map
Does it really matter? I don't really see there being any case where such a thing is going to be checked often or in any context where performance is super relevant?
plugin -> services map since there's no way to get that information without stepping through the services map
Does it really matter? I don't really see there being any case where such a thing is going to be checked often or in any context where performance is super relevant?
I don't necessarily think it is a great idea, but I can see someone coming into discord in due time asking how to do so. Really just a toss up between exposing the service map so they can step through it themselves, implementing such a method, or linking plugin -> service
Resolved the overrides. Not sure why the ProtocolVersion 1.15.2 updates are showing now, but will sort out later
Plenty of signs this is still a WIP. What more updates could you want?
I mean, haven't been updated for like 7 months now and i think it's a dead wip?
Plenty of signs this is still a WIP. What more updates could you want?
I mean, haven't been updated for like 7 months now and i think it's a dead wip? I left this as WIP for input from anyone that wanted changes made before it was merged, but it appears it's fine in its current form. RTM after review.