Should there be a minimalistic version of the Sponge API?

Hello all,

I am server owner and a Bukkit plugin developer. I am interested in the development of Sponge and believe it has a lot of potential. One thing I noticed about Bukkit was that it took a fair amount of time to update between Minecraft versions. As a developer, I understand that the Bukkit API was huge and patching the implementation was time consuming.

Now Sponge (correct me if I’m wrong, I’m new here) is designed a cross platform API with several implementations for each platform. While I love this idea and think it is a very open approach, I am a bit worried that with this approach, it will take a while for Sponge to be updated between Minecraft versions. So I was wondering, should there be a minimalistic version of the Sponge API?

I’m suggesting that we do still create a full fledged API, but that we should also designate a limited subset of that API as a Sponge Basic API. That would allow the Sponge team to target updating that section of the API and implementation first. This would also make it easier to port this subset to other platforms. Plugin developers could then choose to develop only for the Sponge Basic API (for plugins that don’t require that advanced functionality), which would allow their plugins to run on the basic implementation.

This is just a thought that I want to share with the Sponge community and see what everyone what everyone thinks.

1 Like

The full fledged api part ask @sk89q or another lead-developer.

Nice idea, but probably creates a lot of extra work.

This could be a decent idea. Although if they do that the full-fetched Sponge API would be a even longer update. And most people still stay on the old update untill everything is working correctly.

I’m saying we designate part of the full API as a basic API (not sure how feasible this is; I don’t know how interdependent different parts of the API are going to be). When a new version of Minecraft comes out, the focus would be on patching the basic part of the implementation, and then publishing that minimalistic implementation. Then after that, patch the rest of the API. I’m not sure if this would really make the full API a longer update.

By design the Sponge API is as minimalistic as possible while still retaining most use-cases. It’s like the 80/20 rule: 80% of plugin-related use cases are covered by 20% of possible API surface area. We are actively trying to keep it as useful and small as possible, but of course there are quite a few things that can be done differently and there is still a lot even for a ‘basic’ API. This is not counting the ECS(which at this point can be counted as a separate project), so rest assured that Sponge is doing its best to remain relevant and useful while still being relatively small.

Currently the Sponge API is around 8,500 lines of code , and while there is still quite a bit to do I expect it to eventually still stay under 20,000. As a comparison, Bukkit was around 60,000 lines of code for the API. Admittedly both statistics are a bit skewed because they’re very simple code counts(find src/main/java | xargs wc -l), but it does give a good ballpark estimate to how complicated Sponge is currently.