Sorry, i havent been active lately, been working on getting a new gamemode working for reactivemc.
Im not too sure about the Factory design. For classes which require more setting up that could not be done in a constructor or was cumbersome or difficult in a constructor then i think a factory would be very useful although if you were required to use a factory for simple classes such as creating an entity i think that would get annoying.
On the question of the API and Server implementation being built in the same projecti think it could cause confusion for some people for imports. For example importing net.tridentsdk.entity.living.TridentCow instead of net.tridentsdk.api.entity.living.Cow (This is probably not the best example as im sure there are other classes with easier to mix up names). Also, net.tridentsdk.* seems more what your supposed to use at a glance compared to net.tridentsdk.api.*. I also would discourage putting the version name in the path (eg. net.tridentsdk.1_8_1.*) as this would just make it harder for people to use the server implementation directly which people would end up doing anyway with reflection.
I dont see the point in changing the names of the classes from names we are familiar with (such as Player, Cow, Plugin) unless the class did not do what we would assume from its name. For example, if a class was called Permissions we would assume it was describing a list of permissions but if it was actually a class which handled the plugins which supplied the permissions this would be misleading and instead a better name could be PermissionManager or PermissionHandler.
- I think each plugin should get a UUID
I would also like to see an api for the handling of packets. This would probably include a way to:
- monitor outgoing/incoming packets
- Send packets to client
- Register custom packets to allow for people to setup features which are not yet supported by trident (eg. when mc updated to 1.8 server owners could be able to register custom packets to allow them to send titles, action bar text and tablist headers and footers)
- Possibly a way to fake a packet recieval on the server. Not really sure what this would be used for tbh but might be cool.
Also this would be my opinions for a permissions api:
abstract class PermissionSupplier
- constructor ( Player player )
- abstract boolean hasPermission( Permission permission )
- abstract boolean hasPermission( String permission )
- Map< UUID, List< Class< ? extends PermissionSupplier > > >
- void registerSupplier( Plugin plugin, Class< ? extends PermissionSupplier > supplier )
- void unregisterSupplier( Class< ? extends PermissionSupplier > supplier )
- void unregisterSuppliers( Plugin p )
- void unregisterSuppliers( UUID uuid )
The plugins would then register there permission suppliers in there onEnable. Probably create some checks when registering to make sure the plugin is enabled and on plugin disable remove any suppliers related to the plugin.