Feedback on API Design Thread #1

4 years ago

Avatar of xTrollxDudex
xTrollxDudex, Admin
Offline

We'd like to hear your opinions on how you'd like the API to be designed!

 

Particularly, 3 main items:

  • Would you like the API/Server implementation built in the same project?
  • Do you like the Factories design?
  • Do you / would you like new names for classes

The sources for my bleeding edges have been pulled into the primary repositories. You can find them on our GitHub, and there are changes (16 to 17 thousand lines of changes) both in the API/implementation.

Any other suggestions would be awesome!

Last edit by xTrollxDudex, 4 years ago
0

Feedback on API Design Thread #2

4 years ago

Avatar of Pookeythekid
Pookeythekid, Member
Offline
  • Same-project API-server implementation would be great!
  • What is the Factories design?
  • It doesn't really matter to me what the names of the classes are, but it doesn't really seem necessary to change them either. It would be best that the rather confusing class names (if any) be changed, though. For example, once I saw a thread were someone was asking about the "Permissible" class since he was a little confused about it, and the reply said that it was pretty much the best name that came to mind.
Last edit by Pookeythekid, 4 years ago
0

Feedback on API Design Thread #3

4 years ago

Avatar of sothatsit
sothatsit, Member
Offline

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.

 

Random notes:

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

 

PermissionManager class

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

Last edit by sothatsit, 4 years ago
0

Feedback on API Design Thread #4

4 years ago

Avatar of xTrollxDudex
xTrollxDudex, Admin
Offline

This is the Factories design. It's basically the idea that you have one stop to get whatever you need.

 

I think the verdict for the same API/Server is a no. Mazen doesn't support it, it would probably get very confusing. Any arguments for this?

Factories is something I'm very strongly for. It was designed to be easy to understand and shortened method names. If there's something that I can improve to keep it, I'd do it.

We aren't planning to add version names.

Alright, the files won't be renamed.

 

Why should we have a UUID for each plugin? String identifiers should be enough. What's the reasoning behind the addition of UUIDs?

Once the protocol is finished, we will consider adding support for Packet manipulation.

The API, at this point, is very immature. We will also consider the design of permissions later on.

 

Thanks to you both!

0

Feedback on API Design Thread #5

4 years ago

Avatar of sothatsit
sothatsit, Member
Offline

xTrollxDudex,

 

Thinking more about it i dont see the point in a uuid per plugin. It was just something i thought of while writing the post.

0

Feedback on API Design Thread #6

4 years ago

Avatar of Pookeythekid
Pookeythekid, Member
Offline

Eh, I guess the same-project API and server may not work out in some cases. I figured there wouldn't be much wrong with it, since the plugins I've made with Bukkit were all built off of craftbukkit.jar, and when I switched them to bukkit.jar they all still worked perfectly fine. But perhaps I was only using the things that both files had in common.

As for the Factories: I would say I'm still pretty basic in Java compared to other developers, and I'm pretty darn tired right now, so I didn't really read the code. But as long as it's easy to use and isn't complicated to understand, I think it'd work out especially for beginners (or people like me :P). However simplicity could possibly make things harder to use at times; for example, the reason why things can often be hard to build with Minecraft blocks.

0

Feedback on API Design Thread #7

4 years ago

Avatar of sothatsit
sothatsit, Member
Offline

Pookeythekid, the server implementation has the api as a dependancy so if you are using it you naturally get to be able to use the api as well.

0

Feedback on API Design Thread #8

4 years ago

Avatar of Pookeythekid
Pookeythekid, Member
Offline

Ah, okay. Although it's a little off topic, I have a new question. I've heard that CraftBukkit aimed for more stability and less speed, and Spigot aimed for more speed and less stability, but what does Trident target? The best of both?

0

Feedback on API Design Thread #9

4 years ago

Avatar of xTrollxDudex
xTrollxDudex, Admin
Offline

Pookeythekid,

I would think we are like CraftBukkit; our API and server are mature enough for a test release, however we are holding back from it (albeit the fact that it is well tested and needs futher debugging, and that it doesn't function fully yet)

Last edit by MazenK, 4 years ago
0

Feedback on API Design Thread #10

4 years ago

Avatar of MazenK
MazenK, Admin
Offline

Pookeythekid:

To be specific, we try to aim for the best of both worlds. We use a multi-threaded design for our tasks to increase performance, while doing this there are some drawbacks such as getting complete concurrency among the threads. While we do have some tools which will stress test our stability when it comes to how we deal with concurrency, there will always be atleast a very slight drawback in stability.

Regarding the "enterprise" design (including factories, builders, providers, etc.), I personally find it quite an interesting one and I am starting to use it more in private projects however this is an opinion and differs between one person to another. Due to this, I personally believe we should try to add the design appropriately and not take a larger than needed step. As we can see from other server implementations, there are small steps made to have these designs; as seen here, here and here. About the actual design itself, it can be very useful and generally flow much better in code in many scenerios, however there are many other scenerios where the design will make the code verbose, ugly, and/or difficult to use. Furthermore, using this or any other design in a certain area needs to be seen in Java psudeo-code and taken opinion from mutliple developers to make an educated decision whether the design fits or not. Once we have the ability to do so, we can move on to expand to different designs.

0
Copyright © 2018 TridentSDK
Made by Vilsol