Status Update - 6/21/2016 #294
Replies: 5 comments 1 reply
-
zacharee wrote at Jun 21 2016 18:03:51 UTC:
I'm really excited to try out the new API method, since copying keys around different PHP files is really annoying. Will the GET and POST methods stay the same, though (will I just have to update URLs and take out headers), or will I need to redo stuff? And will it be documented this time? :p This build sounds like it's going to be amazing. Can't wait! |
Beta Was this translation helpful? Give feedback.
-
zacharee wrote at Jun 21 2016 18:03:51 UTC: OK. I'm fine if it works or if it doesn't. After all, it's a way to learn more PHP (even if I can't stand it). As long as I don't have too dig through your source code again to find what I'm supposed to do, I'm good :p. |
Beta Was this translation helpful? Give feedback.
-
A deleted user wrote at Jun 21 2016 18:03:51 UTC: LordRalex Thank you for continue the great project! |
Beta Was this translation helpful? Give feedback.
-
leang_97 wrote at Jun 21 2016 18:03:51 UTC: arghhhhh , been waiting for this !!! Waiting for good news!!! Really excited about what will it be looked like. |
Beta Was this translation helpful? Give feedback.
-
blake0201 wrote at Jun 21 2016 18:03:51 UTC: Yes!!! Finaly, I've been waiting for this :) |
Beta Was this translation helpful? Give feedback.
-
LordRalex wrote at Jun 21 2016 18:03:51 UTC:
We know that we have not been making any public releases in some time, and that we have been mostly silent outside of our IRC channel about the current status of the project.
Rest assured, this is not because we are dead. We are just busy.
Since both heads have acquired full-time jobs, our ability to dedicate large amounts of time to this project has been hampered, but we are not letting this stop us. We have been working behind the scenes to prepare and plan for the new pufferd project, and looking to see how we can improve the user experience as a whole.
Puffrfish has been active on our community forum, helping out our users with their problems, and just giving off the light of “we are still here”, and we are thankful for that.
This last week, Lord_Ralex has been pushing large amounts of code to get pufferd to a working state, and so far it’s been promising. While the framework for it is basic, it has already demonstrated a drastic improvement in the quality and design over Scales, and we are confident that pufferd will be a completely better experience in the usability, customization, and installation.
We are at this current moment planning on a new release plan for pufferd when most of the basic implementation is in place to begin moving users off of Scales and onto the new daemon. What will happen is the following:
A minor release of PufferPanel will be required to allow for talking to pufferd and to resolve minor bugs with the panel. While pufferd was planned to be a drop-in replacement, it has been determined that while this is a goal, we are not going to keep it as a hard requirement. One place where this will not remain is the API itself. Pufferd uses a new API method, which we believe is clearer and simpler to use over Scales. This new API will be consumed by PufferPanel and so a code change is required for us to do that. We do hope the new API will be friendlier to users and administrators, and makes creation of billing and deployment modules that much easier to make.
Pufferd will go through alpha releases once the minor release is ready. As part of the release scheduled above, one option we are considering is the ability to select which daemon to use. This would mean that you could use pufferd on the minor release and help test, or use Scales until its ready. This is a goal, so we may not allow the option to select if we determine the effort is too great.
We will incorporate version checking into pufferd and likely PufferPanel to help notify users when the software needs update, as pufferd will need several updates to become completely ready. We will not be doing auto-updates, just update notification.
We do not have any ETAs for when this will be ready, as things come up. We are hoping to have an alpha build “use-able” in the near future, but since we are using Golang, distribution of pufferd is a bit more work on our end, and that’s not in place yet.
PufferD has so far been promising, allowing for a much more flexible system both internally and externally, and small testing has allowed for a much cleaner install process for servers, and allowing the flexibility to change how a server in general works.
The biggest change to how servers are generated is through a new “template” system. Instead of hardcoding a server type into the program and hoping it works correctly, we have moved to a generic type process, and define templates that are used when a server is made. This means that the same code that powers Vanilla Minecraft is shared with Spigot and their Craftbukkit build (which internally we call fakecraftbukkit, but that’s a choice by Lord_Ralex, not by the project). With that, each process can build differently, but use the same code to work. To add in Forge would require a small json file change, and it would then be supported. Modpack support from FTB would follow suite, by just needing json files, which is a drastic improvement over Scales. We hope this new system will allow for a much wider scope, such as permitting Starmade servers or any other Java-driven application without requiring any code change, and just creating a new template json. This same concept will apply to other processes, so SRCDS servers would end up following this pattern, being defined under a generic SRCDS package and json templates would define what type of server it is and how to create and run it. One great improvement with this system is that we hope to allow creation of servers on Windows, which is not possible with Scales.
Our templates currently in use can be viewed here: https://github.com/PufferPanel/pufferd/blob/master/data/templates/minecraft.go
The next change moving forward is server file location. Scales currently populates 2 directories: /srv/scales and /home. Since the use of /home and creating system users is a bit impractical, pufferd only uses /srv/pufferd for all files, including servers. This means to remove PufferD is simply deleting this folder. Currently, the internal system does not containerize any servers, but we plan to keep this structure when we add back containers, but not add tons of system users and /home directories which make removing Scales harder.
Finally, our new API. This API differs from Scales in that we are no longer using the header for any values, which made calling the API much more difficult. We have changed this to using strictly URL parameters, which will still remain secure when HTTPS is used. We have not yet forced HTTPS, but there are plans to do so.
This means our new API has changed from this:
To this:
This new API is a lot cleaner and simpler to use, and we hope will help creation of new modules.
We are very excited for our plans for PufferD, and we hope we have explained why we have been silent for a while. We know that there are issues with our software, and we hope this new daemon will help resolve many of those issues that currently plague Scales.
As always, thank you for using PufferPanel!
Beta Was this translation helpful? Give feedback.
All reactions