Phase - B

Team. We chose an incremental and evolutionary build model for our "general-purpose" controller. Its conception was in the embryonic form of a script or program which simply printed "Hello, World!" This was phase A of our nine step life-cycle. The next and current phase simply prints "Hello, World!", but it uses a function for doing so.

For those of you who understand the processing behavior of programming languages, you are well aware that the main routine must build and populate an activation frame for the subroutines that we invoke and place them upon the call stack in last-in first-out (LIFO) order. At a minimum, this will be the "sendResponse" procedure which echoes "Hello, World!" on the terminal's screen. This is above and beyond the "main" routine which invokes "sendResponse".

The building and population of an activation frame on the call stack takes time and memory space. Since it requires interacting with main memory, this time expended is rather large in comparison with time required for a single processor cycle. So, using these subroutines "slows" the processing of our scripts and programs some when they are not required. However, structuring the controller with them improves its readability and maintainability. This enhances other aspects of quality such as resilience, reliability, and robustness. These are all benefits of greater modularity and structure.

Phase B is simply our next nascent, naif-like step in the direction of a kernel for a "general-purpose" controller. Our final product might require some minor retrofitting before it integrates "smoothly" with the equivalent of a common gateway process, such as a JAVA Enterprise Edition servlet.

The archive for this phase was modified with comments after its behaviors were checked. Plus, the identifier for some of the "sendResponse" and "send_response" modules was modified from "sendingResponse" and "sending_response". These "typos" with the "ing" were introduced while coding the scripts and programs in parallel. As a result, an error might arise when compiling or interpreting these files. One can simply correct the module's identifier, and it should work without any issues.

Some of the languages, like Clojure did not integrate well with MS Visual Studio Code for the author. Others might see better results. As a "work-around", the author created Windows batch files for running and also possibly compiling the scripts. These are labelled "run.bat" in each language directory of the archive.

For the languages which normally use "camel-casing", such as "sendResponse", this was the name used for the identifiers. The only exception was the name of the class, when a class was used. In this instance, the first letter was lower-cased, and it was named "caboose". Classes were used for the languages which are commonly known as object-oriented. This includes C#, C++, and JAVA. Eventually, all of the languages which will support objects will have an object-oriented solution. The classes simply have not been integrated yet.

For the other languages who do not "usually" use camel-casing, the traditional "snake-casing" such as "send_response", was used.

Future Directions

Phase - C will read the phrase "Hello, World!" from a text-file and print it. This will require handling all of the possible file-handling exceptions that might occur. This might simply be done at the level of the general exception class for simplicity. Yet, processing the individual sub-classes of exception might be "wise" and produce a more "user-friendly" product.

Phase - D will simply read an HTML-template with a data placeholder in its body from the file-system and echo it on the screen. In this step, all we must do is replace the filename and path of the "Hello, World!" text-file with that of our HTML-template in the Storyboard folder.

Our tentative goal is completing this pair of phases by the end of June 22, 2020.