Module writeup

[WcaleNieWolny]

It has been a while since the last project update. Weeks went by and there was no update on the project whatsoever. That's why I am creating this issue. It is important that we start the project. We really have the potential to create something awesome! We just need to work on it. For now, I want to present module writeup so some coding can start happening. My plan:

common

api

spigot -> 
        1.8
        1.18
        1.19
        etc

velocity

communication ->
            common
            mysql (depend on communication.common)
            redis (depend on communication.common)
            etc    

Note: spigot and communication are root modules for specific implementation. As we settled in the issues' page we want a lot of abstraction.

I think that this is good enough for now. As bopke stated we need a simple demo before we can do crazy enterprise things. I am open for any discussion about this

[dasavick]

Don't push. You need to take it easy. You're talking about a simple demo and then introducing three or more (sic!) separate versions. That makes no sense whatsoever on so many levels. You don't need per-version modules for this project, unless you want to only make things more complicated and less reliable on purpose. It all can be done with the component feature levels and a single module.

I bet you probably don't even need common modules. I'm sorry, but the common thing is called API. Seems like creating modules for the sake of creating modules, and not for the solving of problems. If you ever find yourself creating short utility functions for simple, unrelated to the core of the project things, and you think it is best to have a separate module for it – it is not.

[WcaleNieWolny]

I bet you probably don't even need common modules.

Right. So how do you get about creating an abstraction layer for connecting to a database or a message broker? We need communication.common to do the abstraction

Next let's talk about spigot and multiversion. The 1.8 is over six years old. It is just stupid to build anything new on such old API. As we discussed previously we need to start with 1.8 due to its lack of features so again no - I am not introducing three or more separate versions. Just saying that this is the basics that we need to do in the future.

I'm sorry, but the common thing is called API

NO! Api is for accessing the plugin for developers and not for creating common implementation (such as DatabaseControllerFactory etc) that are going to change rapidly. Adding common implementation there is a very bad idea.

[WcaleNieWolny]

Also, we do not want everything to be accessible for the developer. Some parts of the code should be accessed only internally.

[dasavick]

Right. So how do you get about creating an abstraction layer for connecting to a database or a message broker? We need communication.common to do the abstraction

This is a part of the API, but not for the Minecraft plugin developers, but for the platform developers. It should be possible to use the own data layer without messing with the core of the project. Otherwise, the abstraction is no good.

Next let's talk about spigot and multiversion. The 1.8 is over six years old. It is just stupid to build anything new on such old API. As we discussed previously we need to start with 1.8 due to its lack of features so again no - I am not introducing three or more separate versions. Just saying that this is the basics that we need to do in the future.

You really don't need any of that, especially for the demo. Just think about component feature levels again. You can easily detect if FunnySectors needs to enable a specific feature. There really shouldn't be anything that requires so much version separation here, unless you like duplicating the code for no reason.

NO! Api is for accessing the plugin for developers and not for creating common implementation (such as DatabaseControllerFactory etc) that are going to change rapidly. Adding common implementation there is a very bad idea.

Not sure what are you talking about, but there is this thing called unstable API. Also, if your DatabaseControllerFactory methods are rapidly changing, you must be doing something very, very wrong. Besides, who cares for the demo and the project in the 0.x.y or even 0.0.y version? It's in the spec that there will be breaking changes. You shouldn't even try to keep it backwards compatible with anything at this point.

[WcaleNieWolny]

It should be possible to use the own data layer without messing with the core of the project. Otherwise, the abstraction is no good.

I agree. I guess it is fine to use component base system for spigot for now. So that is how you see it?

api (package for database, message broker, developer api etc)

velocity

spigot 

Please tell me if I misunderstood you

[WcaleNieWolny]

We might need to add some NMS later when we start implementing 1.18 so yeah i do think that in the future multiple spigot modules might be required but for now we can just do it simple

[dasavick]

I guess it is fine to use component base system for spigot for now.

It is not component base system but component feature levels. Almost anything can be called a component.

(package for database, message broker, developer api etc)

You have gone from too much separation to not enough separation. 😆

We might need to add some NMS later when we start implementing 1.18 so yeah i do think that in the future multiple spigot modules might be required but for now we can just do it simple

Why would you need NMS in this project?

[WcaleNieWolny]

(package for database, message broker, developer api etc)

You have gone from too much separation to not enough separation. laughing

Then please show me how would you like it to be. Do a simple writeup.

We might need to add some NMS later when we start implementing 1.18 so yeah i do think that in the future multiple spigot modules might be required but for now we can just do it simple

Why would you need NMS in this project?

I am not sure if 1.8 have any way of serializing player data other than NMS

[WcaleNieWolny]

So... As it has been discussed we are going to split the code like this:

api (storage, broker, client aka spigot, server aka proxy, dev api)
storage-mysql
broker-redis
client-bukkit
server-velocity

[bopke]

So, if it was discussed, why not? It can always be changed if something grabs our attention later on. I think that changing name from storage to database may be a good idea.