Permission aliases are just there for convenience. You could very well get away with copy and paste.
@octoshrimpy It would not really be bloated. Inheritance and a hierarchical permission system would actually be much easier to maintain and modify. This would also provide a cleaner approach than 1 single file that is hundreds of lines long. In my opinion it would probably be worth going the extra mile with a clean and efficient permission system, since practically every server utilizing plugins requires permissions of some sort in order to function. This cleaner system, in tandem with the more flexible HOCON config system could also help server owners worry less about the little things in setting up a server.
1 Like
Hmm…I’ve examined your comments, and think that aliases and permissions aliases are not required.
I still believe that having a basic feature like Vault API for economy chat and permissions would be essential.
i think one the problems with bukkit was that the core itself was not particularly liked by the community.
1 Like
I would appreciate a permission, economy, and chat api. Not a fully-fledged plugin for any of those built in.
Diversity is good; as is competition to make everyone’s individual plugins the best they can be.
On a personal note, I really don’t even want economy, nor do I really care to have my permission and chat systems locked in to only one option - the Sponge everything-in-one manager.
</$0.02>
2 Likes
I don’t think we need a permissions system but a permissions wrapper which communicates with other permission plugins. e.g.
If(e.GetPlayer().HasPermission(“some.lucky.cat”)) {
System.print(“Cause I’m lucky.”);
}
instead of:
if(PluginName.HasPermission(“some.lucky.cat”)) {
System.print(“Cause I’m lucky.”);
}
This allows most if not all permission plugins to work instead of just one permission plugin. I am pretty sure Vault does this already but I don’t remember.
Having a wrapper also means it would be easier to learn how to check for permissions since you would only need to learn once not a million times.
1 Like
Please read that:
You beat me to it!
The only thing that I think could even be considered to implement into the core is vault. Any other thing simply bloats the core and restricts that user to that particular permission system. Plugins are there for a purpose, make them and use them.
- permissions… okay, but only as an API feature (so it’s unified), nothing like a complete permissions suite (which is what PEX is)
- economy: too specific imo. lot’s of servers that will be running sponge don’t want economy. It should be the goal of sponge to provide things that are common, but be as slim as possible at the same time. And economy ain’t one of those things everyone needs.
- Aliases, command parsers etc are something that should definitely be in and is on the todo for the API afaik.
- permission aliases: permissions should always be explicit for clarity’s sake.
“Because Sponge DOES NOT add blocks, logging, items, your favorite animal, etc. to the game. It exists to provide the tools necessary for developers to do that,”
However, I’m not asking for blocks, items, etc.
Permissions is something that was in Bukkit, but could heavily be improved upon.
They do plan to improve permissions.
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: