I think they mentioned that this is simply an API layer that adds absolutely no functionality to Sponge unless a plugin extending Lapis is installed. So there wouldn’t be anything to edit. They may be able to add some API stuff to making altering stuff easier, but it’d ultimately be up to the plugin devs writing plugins for Lapis.
Yea 
Saw that after I posted. Thanks! 
Absolutely! We’ve been talking with Sponge team throughout this whole process, and I don’t think there’s a single one of us that hasn’t sent in both developer forms. We’ve been ubiquitous voices throughout the discussions of ECS, permissions, metadata, and commands. Contribution to Sponge is our first impulse and an ongoing effort from all of us.
Lapis’s role in all this is for things which do not belong in Sponge. Sponge commands, for instance, will not have any annotation system, and will not have any facility for resolving tokens into game objects. It won’t even tokenize the String for you the way Bukkit would. But it’s precisely this simple, straightforward design that allows extremely high-performance bindings and interchangeability between Lapis and Sponge commands.
The mod community kind of misuses “API”. That’s why I prefer toolkit or commons, because this is less of a shared interface and more just making a good implementation available of features that are more specific than what Sponge provides.
4 Likes
I just saw this excellent post by sk89q about the various pieces of the Minecraft plugin and modding ecology, and thought, that’s a fantastic way to explain where Lapis sits in the stack!
As shown, the Lapis stack neither touches Forge nor user-space. You place java or lua plugins on top of Lapis, and/or use our own optional vertically-integrated Codex. Also, Commands and Permissions features from Lapis bind down into Sponge to provide basic services for plugins no matter what abstraction they sit on.
6 Likes
I was thinking that Foundation was like Essentials and this was more of an API?
This is the Lapis thread, @Squawkers13. I think Foundation is more alike Essentials than Lapis, but Lapis is more of an API. If you want more information about Foundation, check this thread out instead XP
This seems very very cool! 
I don’t know much about programming (yet), but I can’t wait for this. To me it looks like you’re going to be implementing something sort of like Skript for bukkit offered, except in what looks like a very well-thought-out package deal of all sorts of APIs for plugins to hook into. Which means that amateur server owners (like myself? 
) can make their own plugins for their servers with little knowledge of programming. Needless to say, I’m ecstatic! I wish the lapis dev team good luck.
Also, foundation also looks very cool. However, I think that it would be bad if they tried to merge with lapis, because lapis seems more like a set of APIs for plugins to hook into, and only looks to implement a few utility commands, if any. Foundation seems more like essentials to me, with the end user in mind. Perhaps the lapis and foundation devs could brainstorm ideas and stuff together, though, so that they don’t end up clashing.
2 Likes
@gratimax Some evidences:
- 12 days ago (at this time, and now 12 days ago is Septembre 18th), @Kornagan, developer of Foundation, came up with the idea. We immediatly started discussing on how we wanted to do it. At this time, Lapis didn’t even exist.
- Our first commit which included some APIs were on Septembre 20th, a time this post didn’t even exist, and the outside world didn’t know it either.
And i agree with you on some points, but here are some questions from me:
- Aren’t we allowed to have a website? We began programming one about 1-2 days after you told me.
- Yes, i changed the post a little late: so what? Look at GitHub and the thread…
- Indeed, that graphic stack was inspired, but again, aren’t we allowed to show our plan?
- I changed the FoundationDevTeam to FoundationDriven, because our package naming was com.foundationpowered.foundation. I changed that to FoundationDriven, because the powered was completely unoriginal (SpongePowered, you get it?)
Personally I have to say that so far it does seem like Lapis is more professionally managed and the staff likewise, but I won’t say that it’d hurt to have both teams working on it. Who’s time is anyone really wasting by working on their own version of anything? Only their own, presuming no copyright infringements are involved.
2 Likes
I don’t understand why Permissions and “Buckets” are 2 things. In Bukkit, every permission was a “Bucket”, that means every permission can have child-permissions. Why do you want to separate permissions and “Buckets”?
Stated on the perms page about Buckets:
Because they are not really groups, I chose to adopt a different name: Buckets. A bucket is simply a collection of permissions. It has no other given meaning.
It seems a bit confusing, but I suppose they mean that it isn’t a structure of parent-child permissions (On second look, it kinda is), but rather a label given to a collection of permissions. It’s very very similar by all means. And I suppose as well that it’s only because the labels given don’t really resemble permission nodes. That’s about as best I can describe it. I’d also appreciate some more clarification XD
While, as I said, many things seem dubious at first glance, we should be careful not to throw stones.
-
Our project is MIT. As long as they’re MIT, our licenses would be completely compatible with them taking whole sections of our code and dropping it into their code.
-
You could just as easily say that I copied Sponge’s block diagram, which I freely admit. I actually think it’s a good thing that Foundation is trying to communicate their role in the Sponge plugin ecology as much as we are. All this helps explain to our users what differentiates us and helps them make informed decisions about what to put on their server. Seems nice to me.
-
Our primary responsibility at this moment is to the users, making sure that differences between our projects enrich rather than confound the community.
Leadership on both sides is on the same page on this. First commit on Foundation was a day before us, and we rapidly overtook them in progress, mostly due to having more active programmers. The day after we made our official Lapis post (this one), Foundation made a major update on theirs. We both live in the Sponge plugin ecology and thrive in the user community here on the forums. When something happens here, we both respond in very similar ways. That’s not a sign that anything’s broken.
TL, DR: Peace, fellows. It’s time for peace.
5 Likes
There are two structures here, and we’ve been evolving the permission designs as we continue to talk about them and test implementations. We want to do this right. And to do it right, we have to separate what one might call permission nodes, from what one could call groups.
Permission nodes are typically conceptualized as a tree. For instance:
town
|
|-mayor
| |-rename
| |-sell
| |-tax
|
|-citizen
| |-ownland
| |-vote
In this case, one might prefer to grant all their users town.citizen (town.citizen.* in bukkit), which would in turn imply town.citizen.ownland and town.citizen.vote. So in one sense, town.citizen is a collection of permissions. But that’s not what we mean by buckets.
What you might call groups is a whole different story. This is the conceptual and experimental hotspot in permissions right now, and where the term “bucket” comes from in this usage.
w[FreeForAll] : { build }
w[Creative] : {}
guest : {}
member: { economy, town.citizen }
member > guest
pixel: {}
pixel & w[Creative] : { build }
So we have a number of bucket directives on display here. (and yes, it is appropriate to call them groups, I will do so from here on for simplicity’s sake)
w[FreeForAll] is a world. These are implicit, synthetic groups which Subjects are members of as long as they’re an Entity which is in that World. Same thing for w[Creative].
guest and member are traditional groups, with a traditional inheritance relationship defined between them, member > guest. You could read this as either “member inherits from guest,” or, in terms of set theory, “member is a superset of guest” (it has all the permissions guest does, plus more)
pixel is a more “bucket”-y, behavior-focused group. It describes a role or an activity on the server, in this case pixel artists which should be able to build on the “Creative” world. But wait… this group has no permissions! How are we doing that?
pixel & w[Creative] is what we call an indefinite group. It’s an intersection set between pixel players and players who are in the creative world. In this case, we say that people who meet both conditions should be able to build.
I hope this clears up some of the confusion, and helps express how the permission system has been evolving and its vocabulary and grammar is formalizing. Note that this is still under heavy focus and subject to change.
Edit: and just like that, it changed! Updated for the new “superset” grammar.
4 Likes
Ah, I can kinda see that now. I guess the confusion is in part because permissions as we’re used to them aren’t a proper tree structure despite having the format of being so, rather they’re just Strings with associated true/false values. I guess if permissions are setup as a proper tree-system, then that all makes sense. Thanks for clarifying XP
Is the structures intended to be used compatible with the HOCON format? Or if not, I suppose Lapis would need to provide a utility for managing those files? I’d think it’d be most convenient if an object using that structure can be serialized and directly handled with Sponge’s API for reading/writing configs and such.
We’re going to see if the configuration files will be expressible in HOCON.
The syntax that Falkreon showed above is the one that I originally came up with to express the relations between buckets and permissions. It is certainly possible to express buckets and their relations in YML and JSON, and we’re going to figure that all out later.
1 Like
@Falkreon, @gratimax, @Exstar I’ve not been around Foundation for a week since I’ve had work so I’m not up to date with what’s been going on much less why Lapis and Foundation seem to be taken a piss at each other.
I don’t understand why Lapis or Foundation are copies of each others. Lapis goal seems to be to provide a toolkit for rapid plugin development, Foundation’s is to make a modular Essentials-like plugin with an api open to other plugins. They’re aren’t the same, they don’t do the same thing. Though I admit at some point talks started diverging from that, especially while the scripting stuff, the main goal of the project still remains to be an Essentials-like plugin.
From what I’ve read from this thread and docs on the lapis.blue website, I even believe that part of our implementation of the interfaces could maybe even be built on top of Lapis.
I’d really like both projects to coexist, maybe they even could be one, why not. I really don’t want any animosity between the two teams, especially since I’m thankful of @Falkreon for the talk we had on #spongedev. He is the one that solved our circular dependence problem and suggested a completely different way to handle modules.
2 Likes
@Falkreon, @gratimax, @Exstar nevermind the updates in the Foundation thread never showed up in my notifications. I just read it, now I understand how this problem happened.
The name change, the chart and the website, it’s child play really. I’m dumbfounded this happened and I’m sorry about it. That aside, right now the goal of Foundation is to provide standardized packages for things like mail, bans, jail, teleports, warps, etc. Although some package will probably exists in both Lapis and Foundation, like economy, I don’t think both projects will offer same functionalities.
I’m quite open to talk to the Lapis devs actually.
@Kornagan I agree with you. I already apologized myself. Me and @Falkreon agreed that both projects actually do different things.
1 Like
Well that’s great then 