Page History
...
MVC seeks to solve most of this dilemma by introducing another layer: the Controller. This layer operates between the View (think Client) and the Model (think Server). The controller helps to abstract the other layers, thus enabling more flexibility and better development standards. While some have argued that the basic functionality of the internet is classic client-server, there are others who point out that the use of the HTTP protocol itself performs the function of a controller. That is to say, HTTP is the abstraction layer. This is why browsers do not have to be re-written if a web server gets replaced. As long as the URLs remain the same, the view (i.e., web browser) and the model (i.e., the web server) maintain a healthy separation.
For our purposes, the role of the controller can be broadened to include the OECGI and the pre-configured dispatch routine. By default, this dispatch routine is RUN_OECGI_REQUEST, but replaced with HTTP_MCP for the SRP HTTP Framework. These routines are, for the most part, pass-throughs (or brokers) for the incoming HTTP request and then again for the outgoing HTTP response. Thus, the OECGI and its dispatcher, are another layer between the view and module. With that in mind, we offer the following diagram to help with the big picture understanding of the architectural design that the SRP HTTP Framework follows:
