Notice the etc. 
The point is it an end-user feature, not a feature designed to improve the workflow for development.
Permissions manager: No, I donāt think sponge needs something like this built in- it needs an interface and API for it. Not a built-in permissions manager. Plugins can add on functionality for permissions, a built-in permissions system would just make for a stagnation of thingsā¦ Nobody would develop permissions plugins like PEX because youād have spongeās built-in permissions, and then you end up having no diversity in your options. Perhaps there can be a simple and lightweight permissions structure based solely on OP players and non-OP players built-in which allows for more permission nodes to be added/defined (which leads into your suggestion of permission aliases).
Economy feature: Seems interesting but thereās not any reason to make this a built-in feature, either. External plugins can handle economy fine.
Built-in anticheat: No. This is a horrid idea all around. NCP is a notorious resource hog, and also produces a lot of false-positives. The only anticheat function I can imagine having built-in would be a lightweight anti-xray system like spigot has built in, with an optional toggle (perhaps turned off by default.) In fact that may not even be necessary for minecraft 1.8.x forward because of the recent changes that nerf xraying methods.
Aliases: Iām sure something like complex aliases and permission aliases is in the works, as bukkit did have support for these things. These are a good idea
My two cents:
Not sure if this is better done by a Plugin, can you give me some reasons why it would need to be in sponge?
Of course it would remove the need for a plugin, but choosing the most fitting permission manager for server
seems like a better approach than a one fits all sponge implementation. I donāt see what a permission plugin
could not do that sponge can.
Many servers donāt need/use an economy feature, this sounds like a feature that is perfect for a plugin. Again, I donāt see how a sponge one-fits-all solution would be better.
Yes, absolutely. Cheaters are the worst. But keep it minimal in the sense of performance impact, not all server need anticheat. Also there might be some performance gains with a built-in anti-cheat opposed to a plugin implementation.
Can you give me a reason why this can/should not be a plugin instead of built-in?
1 Like
plugins already have thatā¦ its in the plugin.yml file
what that means, is that because not everyone will want it, they will not include it, but they make it so that you can include it yourself
Itās key to remember that putting something in Sponge directly that is a āFeatureā more than an API actually is bad for you in the long run!
As I said on another thread - If itās in Sponge, it canāt be improved as freely as it has to make sure it doesnāt break anything implementing it.
Also, theres the case of āwhoās using itā. When you go with a plugin controlled route, you get the benefit that the developer of the plugin can put their focus into said plugin, and provide the features they need.
There is self gain that drives the development of the plugin and the features.
Now, if you go putting it into Sponge itself, your personal desires are now restricted to how it affects EVERYONE else too. This can and will limit you at some point.
Thatās why APIās are APIās, they define the basics, then let other things implement.
So stuff like full on permission managers, economy and anti cheat? No, you DONāT want that in Sponge.
This is why I have many powerful APIās in my own custom fork of Spigot that I havenāt contributed upstream. You lose a lot of flexibility when something becomes officially part of the project, and I didnāt want to sacrifice that.
If you want to have a nice permission manager or anti cheat that is free to evolve and become even better, then you donāt want it inside of Sponge core itself.
3 Likes
TL;DR: Putting things that donāt improve the API itself simply bloats it and makes updating harder. Having plugins do the work instead allows for much more freedom and puts less responsibility on the dev team and much less weight on the API.
I have one question: would having an option to enable or disable certain features like Economy API reduce bloating? If itās not enabled, it shouldnāt use as much processing, right?
Or is just adding the code using more memory?
If you read the two post above your one:
NO ā¦ Economy will not be part of the SpongeAPI:
No, having the feature already bloats the core (in the sense of more code), which makes development slower/harder (somebody has to maintain/test all this code).
Processing/memory is not the issue. Sponge is an API. KISS
how do i close this thread
You canāt close it. Iām also not going to close it because there was plenty of good discussion here. Someone else with similar questions can look here to find answers rather than opening a new topic to ask like you did.
1 Like
There already are other threads with same questions
Having a manager is an nd user convenience feature. Giving API functions for permissions improves workflow for developers. The permission manager plugin developer can conveniently use the api features to manage permissions, other mods/plugins developers can conveniently use permissions without and extra API, wether they will be used by server admins or not.