Status update - 26 September, 2014 -> API developer form

[sk89q]

See the previous status update on 16 September.

Hello, everyone! This is the latest status report on the Sponge project.

API developer form

We previously had a form requesting the contact details of people who wished to help with development, but we ended up receiving far too many entries and without enough information to be able to choose respondents and assign them a task.

For that reason, we have a new form that is a lot more specific and will better allow us to pick some individuals who could help with development of the core API. As mentioned in the previous status update, it’s easier for a small group of developers to build out the initial portions of the API rather than attempt to build the API via pull requests.

You can fill out the form here.

(If you are not sure what part of the API needs to be written, continue reading.)

The most important part of the form is the “provide some ideas” input because it will give us a general idea as to whether we think your ideas would pan out well for an API. Remember, an API should be extensible, reusable, and practical. A principle of “least surprise” is important. A good way to test your ideas for an API is to start with writing code that would make use of the API to see if it would flow well.

Pull requests

Please HALT your pull requests. Some are great, some are bad, but currently it’s completely unmanageable for us. If you want to help, please submit the form so we can assign you to a part of the API.

Once we have people assigned to portions of the API, then we can dedicate those people to handling PRs for their area of expertise.

Progress report

While it’s been a balance between work or school and the project for most of us, we’re making progress. With a few new developers, we should be able to get more done more quickly too.

General overview of the API

Pretty much everything (events, permissions, etc.) will be handled through services. All services are accessed through the service manager.

serviceManager.provide(PermissionsService.class)

If you need to get an object reference to something, it will be straight forward: just get it off the service manager.

Designing the API this way makes it extremely modular: it becomes possible to technically turn Sponge into something completely different and completely unrelated, though this is not our goal and only a byproduct of this design.

For convenience, we will probably still provide access to a number of services indirectly:

game.getPluginManager()
player.hasPermission()
// etc.

As we are not targetting Java 8, we don’t have default methods, which would help with the evolution of services. That means that we will have to find a solution to this problem.

(By evolution I mean the updating of service interfaces to a new version. For example, if a PermissionService interface is given a new method, all of its implementing classes would break because they would no longer implement the full interface. As implementations of such a service would reside in plugins, we would not be able to directly update those implementations.)

By area

Note: By “Need mockup for API,” that means that we need to settle on a proposal (what the API would even look like) first.

• Plugin loading: Mostly done
• Core game objects:
  • Block API:
    • Metadata about blocks (isSolid(), etc.): Needs work, not yet assigned
    • Setting/getting blocks: Done
    • Accessing tile entity data (inventory, etc.): Need mockup for API
    • Accessing NBT data: Need mockup for API
  • Entity API:
    • Metadata about entities: Need mockup for API
    • Creating/removing entities: Needs work, not yet assigned
    • Accessing tile entity data: Need mockup for API
    • Accessing NBT data: Need mockup for API
  • Biome API: Not done, waiting on mockups for block + entities
• Game:
  • Game registry (i.e. registry of registered blocks, entities, etc.):
    • Getting instances by ID: Done
    • Enumerating lists of objects: Not done
    • Object -> ID: Done
  • World API: Not yet done
  • World generator API: Low priority
  • Inventory API: Waiting on decisions on how to access tile entity / NBT data
  • Enchantment API: Waiting on decisions on how to access tile entity / NBT data
  • Scoreboard API: Need mockup for API
  • Title API: Need mockup for API
  • Map API: Need mockup for API
• Services:
  • Permissions API: Currently being worked on by zml2008.
  • Event API: More details are to be announced
    • Cause API: Not yet done
  • Command API:
    • Command interfaces: Mostly done
    • Command implementations: Not yet done
    • Command registration service: Not yet done
  • Configuration API: Need to figure out how to integrate Typesafe Config and allow comments + write back of defaults
  • Persistence on game objects API: Need mockup for API
  • External storage persistence API (SQL, NoSQL, etc.): Need mockup for API
  • Conversation API: Need mockup for API
• Utility classes:
  • Chat formatting API: Needs work, not yet assigned
  • Math:
    • Noise generation: Low priority

We may not ship with all of these things by the first release.

What takes the longest in the process?

If we were to plot what takes the longest…

[Aaron1011]

Can we submit the form multiple times for different parts of the API we’re interested in?

[sk89q]

WELL I was on the fence about that, but I guess it’s okay.

Just make sure that you use the same email so we can see all your submissions together.

[Dylan3304]

Progress Looks Great! I look forward to next weeks update. @sk89q, it might be time to starting thinking about making a plugin respiratory.

[BungeeTheCookie]

Thanks @sk89q your the best! I will try my best to make this project as successful as possible!

[sk89q]

I added a section about pull requests.

@sk89q

Pull requests

Please HALT your pull requests. Some are great, some are bad, but currently it’s completely unmanageable for us. If you want to help, please submit the form so we can assign you to a part of the API.

Once we have people assigned to portions of the API, then we can dedicate those people to handling PRs for their area of expertise.

Going forward, having people be responsible for parts of the API is going to be much easier than us having to handle PRs.

[Azewilous]

Thanks for making this developer forum. If I’m accepted I will do my best to add what I can.

[njb_said]

Thanks for the update

[xxmarijnw]

Thank you, @sk89q for Sponge. I will (if i am accepted) to add as much as my fingers can typ.

Yours sincerely,
Marijn van Wezel

[Maulss]

Awwww yes. Sponge is looking good so far.

[bensku]

Thanks for update! One question, will the applied developers get access to Sponge’s Github repo?

[MrMysteri0us]

Nah, please nah.
Sponge != Bukkit/Spigot, Discourse is just something new to get used to.

[SgtOrganon2]

What about something similar to BukkitRunnables? I don’t see anything like that listed there, and isn’t it a pretty widely used feature?

[blablubbabc]

Please try to be consistent about which API calls trigger other API-related things (like events being called) and which don’t. And/Or at least document this kind of behavior for each API method where this might not be completely clear.
For example in bukkit (if I remember correctly) there were some cases which would trigger a related event, and others which wouldn’t: for example manually loading chunks would also trigger a chunk load event, manually unloading chunks however wouldn’t (under certain circumstances, if I remenber correctly). There were a bunch of other situations as well: player.chat() calling a chat event, player.performCommand() not triggering a PlayerCommandPreProcessEvent, etc…
Without any documentation about these kind of behaviors one would have to look into the concrete implementation everytime to figure this kind of behavior out.

[sk89q]

@bensku

One question, will the applied developers get access to Sponge’s Github repo?

Yes.

@SgtOrganon2

What about something similar to BukkitRunnables? I don’t see anything like that listed there, and isn’t it a pretty widely used feature?

That’s planned. Frankly the list is not complete.

@blablubbabc

Please try to be consistent about which API calls trigger other API-related things (like events being called) and which don’t. And/Or at least document this kind of behavior for each API method where this might not be completely clear.

Well we’ll try our best, but it can be sort of a whack-a-mole. If we miss something, be sure to request it later on.

[MazeXD]

@sk89q

Configuration API: Need to figure out how to integrate Typesafe Config and allow comments + write back of defaults

I struggled with the same problem about comments and write defaults in typesafe configs.
Here is my kind of hacky solution:
PatchEngine/src/main/java/patchengine/config/ConfigHandler.java at master · MazeXD/PatchEngine · GitHub and
PatchEngine/src/main/java/patchengine/util/ConfigUtil.java at master · MazeXD/PatchEngine · GitHub

[sk89q]

Since Typesafe config relies on a “defaults” file, is there a way to integrate that to use as the source for defaults?

[MazeXD]

It is possible to use withFallback of ConfigFactory, but as Akka is in the classpath of Forge we won’t be able to use ConfigFactory.load as it would inject Akka’s reference.conf into the config object.

Therefore it would be

File configFile = new File('plugin.conf');
Config config = ConfigFactory.parseFile(configFile)
    .withFallback(ConfigFactory.parseResource('resource/path/to/defaults.conf'))

[zml]

Would it make sense to expose comment handling API in typesafe config itself via PR? Or are the typesafe people against that?