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

Status update - 26 September, 2014 -> API developer form
sk89q wrote:

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


​

Posts: 7

Participants: 4

Read full topic

 

Да, это надолго. Они еще всё хотят моками покрыть, как я вижу.