Thank you for your attention and feedback. This is indeed a problem. This document was written hastily and is incomplete. I will take the time later today to improve this and other documentation. Thank you very much again.
Thanks. And yes, Melon is the core library. Besides the implementation of various common components, it also includes the implementation of the Melang interpreter. The Melang repository contains implementations of the interpreter launcher and libraries.
There are indeed many aspects of the current document that can be improved. I will add them one by one in the future. Thank you very much for your suggestions:-)
Yes, this project is currently relatively simple because it has only been in development for a little over two weeks. Meproc intentionally does not use configuration files in order to achieve better automation. Using configuration files would complicate dynamic updates and automated deployments.
Regarding the termination of processes, the code uses the Kill function. However, it does not provide termination detection. Thank you for the suggestion, it might be a good idea to add this feature. Due to the differences in system APIs between Windows and UNIX, SIGTERM is chosen instead of SIGKILL to ensure compatibility with both platforms.
The issue with the new process not producing any output is mainly due to the differences in the implementation of Melang script on Windows and UNIX. Specifically, the system APIs for launching new processes and redirecting input/output differ significantly between Windows and UNIX, making it challenging to achieve perfect compatibility with Windows at the moment. Currently, the exec function in Melang can retrieve program output on UNIX systems, but it is not used to maintain consistency across both platforms. This is indeed one of the areas that needs improvement in the future.
Thank you for your analysis of the project and providing valuable insights.
I have to admit that Supervisor is much more mature for Meproc, as it has gone through a long process of user feedback and iteration. Meproc, on the other hand, has only recently implemented a rudimentary project. The difference between the two, in my opinion, lies more in their design philosophies. Supervisor was launched earlier, so it heavily relies on configuration files and initially followed a client-server architecture. Later, it added HTTP XML interfaces to address visualization and automation needs. In contrast, Meproc wanted to abandon configuration files from the beginning because they can complicate automation. For example, should the configuration file be updated when new configurations are deployed, and how to ensure consistency between runtime configurations and the contents of the file. To give an inappropriate analogy, Supervisor is like Nginx, a classic software, but it faces challenges in dynamic updates in the current cloud-native environment. That's why alternatives like Unit were developed to compensate for its shortcomings. However, why not design a software from scratch that inherently supports dynamic updates?