2. The main feature of the Limax
The application server processes the request logic and generates the presentation data based on the concept of the View, without using the traditional protocol model. The client directly presents the data, which significantly reduces the logic complexity.
The application design of the protocol model: the server processes the logic functions, generates the output data, defines the protocols based on the functions, packages the data according to the protocol, and sends the data to the client; the client decodes the protocol, and processes the following logic according to the decoded data or directly presents the data.
These processes such as the server packaging source codes, the server communicating the source codes, and the client decodes the source codes could be automatically generated according to the protocols. It sounds amazing and many issues have been resolved. However, is there any defect?
The concept of the protocol has no any problem. Even the ISO has 7 tier protocol, and all kinds of protocols are used in the network. The biggest problem is how to correctly design the protocol, which is the result continuing to weigh the compromise. There are two biggest issues: the granularity, and the sequence.
The granularity -- when implementing a complicity application, the server need to transfer all kinds of datum. How many protocols to be designed are appropriate? If the protocols designed are limited as little as possible , some protocols might include the redundant datum, that causes the client to identify which data is necessary and which one is redundant through analyzing the related context. This is the one of the logical functions which acceptor must process even though these logical functions have no any relationship with the detailed project. If the protocols designed are expanded as many as possible, how to maintain the hundreds of the protocols? Even the amount of the protocols may be reduced through reusing the protocol, more serious issue which is related to the whole project may be caused, and the maintenance is harder.
The sequence -- It is possible to send many pieces of protocols when implementing one function. It is need to considerate the following questions: which protocol should be sent firstly by the server, which one is the next, which protocol will be processed in the first place by the client and which one is the last. There are two choices when designing the logical functions in the server in order to properly process the order. Firstly, the protocol will be sent as needed in the processing. However, there is a problem that the sent protocol could not be recalled when the next operation causes the rollback in a transaction logic. Secondly, Protocols could be organized and sent out based on the result data after the logical function has been finished. It is acceptable for the static order of the protocol organization. (Two protocols A and B, B always is sent behind the A, that is called the static order.) However, it is a big trouble to handle if the dynamic order of the protocol organization uses this choice.(Two protocols A and B, which should be sent firstly is decided by the execution result of the application, that is called the dynamic order.) Is it possible to package all the datum related to a function into one protocol to reduce the complexity of the server? If so, the client need to resolve the issue that which order is applied in a protocol to present the fields, and the client also has to handle the logic function at the same time. For example, the server requires to process the events in this order: turning off the light first, then turning on the light. All these events are packaged into one protocol and sent to the client. After receiving the protocol, the client gets into the trouble that how to present the sequence? First turn off the light then turn on the light? Fist turn on the light then turn off the light? It is crazy.
The granularity and the sequence should be integrated to be considered at the same time. If the sequence is simplified for the design, the granularity of the protocol will be thicker, which causes the redundancy. The client has to identify the redundancy and present the sequence. If the design focuses on the meticulous granularity, the maintenance cost will be sharply increased and the sequence design for the server will be harder. Actually, this is a contradiction.
This contradiction could not be resolved in the protocol model design, but be reconciled. It is hardly impossible for the client and the server to avoid the logic processing which is not related to the final requirements, which not only brings the high cost, but also causes the bugs. The reconciled design is hard to be maintained when the requirements are changed. When the reconciled design is changed to another one, there might be a big problem: all the logic processing which is not related to the final requirements need to be found out and modified carefully. However, sometimes, some logic processing is just in the head of some developers. That will be the disaster to the project.
The uncertainty caused by reconciled application design is gotten rid of due to no protocol model used. Limax presents the MVC in the data meaning by using the concept of the View, avoids the granularity issue -- only the data which is changed will be sent; clarities the sequence factor -- the client totally reproduces the modification order of the view changed by the server.