[Abandoned] Lapis Commons: Unified toolkit for rapid Sponge plugin development

Plugins Plugin Development
43

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
44

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
45

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

46

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.

47

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
48

@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
49

@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.

50

@Kornagan I agree with you. I already apologized myself. Me and @Falkreon agreed that both projects actually do different things.

1 Like
51

Well that’s great then :slight_smile:

52

This sounds fantastic. I am rather excited to see where development takes this project. I especially like the theory behind your permissions system.

Nicely done indeed ;D

53

I’m trying to develope a plugin for Lapis, but I cannot find a Maven repository to build off of. Is there one?

54

LapisCommons is more or less abandoned at this point, as its lead developers have been working on SpongeAPI and thus have migrated most of its functionality there.

2 Likes