Status Update - 9/2/2016 #362
Replies: 5 comments 6 replies
-
falceso wrote at Sep 2 2016 21:58:01 UTC: Finally an update.. |
Beta Was this translation helpful? Give feedback.
-
MattBSG wrote at Sep 2 2016 21:58:01 UTC: Don't listen to them. If they cared then they would see all the stuff you have worked on constantly in the dev branch on github. Aside from that point, I will make sure to provide feedback in the form of issues on github when I notice things to aid in getting pufferd out of alpha |
Beta Was this translation helpful? Give feedback.
-
falceso wrote at Sep 2 2016 21:58:01 UTC: Everyone please move your topics about me to a private message. As that is not required for this thread. You may post your be confidence about the development here. |
Beta Was this translation helpful? Give feedback.
-
Small-Ku wrote at Sep 2 2016 21:58:01 UTC: Looking forward to the releasing of a completely new pufferpanel in future. Thank you for the hard working:3 (Sorry,my English is poor) |
Beta Was this translation helpful? Give feedback.
-
A deleted user wrote at Sep 2 2016 21:58:01 UTC: Thank you for keep informated all us about deveploment ^^, a question, all stuffs make for now are upgradable to this vesion? |
Beta Was this translation helpful? Give feedback.
-
LordRalex wrote at Sep 2 2016 21:58:01 UTC:
Another month, another large amount of work.
The last 2 weeks have been filled with a lot of work achieved and a lot of decisions being made. We have continued to work on the new daemon, and are much closer to it being in an alpha state for functionality testing. We have been able to deploy the daemon to our dev version of the panel and validate that it at least functions, which is a great start, but we still have a lot of work to do before it is ready.
We have created 2 milestones that will demonstrate when we expect the alpha release to occur:
https://github.com/PufferPanel/PufferPanel/milestone/14
https://github.com/PufferPanel/pufferd/milestone/1
Both of those we hope to be ready by the end of this month, and so we are excited to see what the new daemon will be doing for us.
The major focus of the new daemon is an emphasis on flexibility as a whole, and so the core design is built around each server doing what they need, not a generic "end-all" solution that Scales was using. Each server uses a configuration file to drive how it functions, adding much needed flexibility to servers. Each server type is defined from those templates, which is copied (for now) when a new server is created. This means that Server A can define extra java arguments or even use a different version of Java compared to server B. The panel is going to get updates that allows for administrators to control this data, but this may not be done with the first release.
We have temporarily removed the tracking of the stats of a server as it is an extra feature of the daemon, and is not a focus on the first release. You may notice additional features missing as the new daemon does not currently handle those yet, but we will be working to restore what functionality that we can as the daemon progresses.
We are very pleased with how the daemon is progressing, and hope to keep this daemon for the foreseeable future. The language that we chose to use does not support a traditional plugin architecture, but we have found that the design we have chosen allows for enough customization to the servers to be acceptable for most use cases. We will instead have the UI build on top of this and expose that extra functionality that is sometimes needed, and using the daemon's API to achieve that.
A good example would be the auto-accept EULA for MC servers. We would not be coding this on the daemon itself, but having the panel determining this on starting/installing the server (as installing is now done via the user and not via the server creation, a huge change as well), and prompting the user to accept it. When it would, it would upload the eula.txt to the server so that it "accepts". That would be how the daemon could indirectly support it, but not require any special code on the daemon to handle it. Plugin management could follow along with that, being driven by the panel's UI. This is our plan, but time will tell to determine how it eventually is implemented.
A few key changes to recap in the event it was not mentioned in previous updates:
Beta Was this translation helpful? Give feedback.
All reactions