Excerpt from Daniel ---- "evaluate the degree of reliability of middleware"

Whether the middleware is reliable or not, it often takes time, effort, and labor to test the situation in the early stage.

If there is a cost, you can try it at will, but it is really bad to try something else from the beginning.

I read the article published by Daniel. It's a good one. I just want to extract it.

1. Integration complexity. Good middleware features a high degree of modularity (that is to say, it does not expose unrelated interfaces at Will) and minimal intrusion (normal use does not require strong coupling relationships such as inheritance ), it is easy to integrate into different types of code libraries (such as using portable code instead of calling platform APIs as much as possible). There are very few assumptions about the external environment, it is strongly decoupled from the implementation details of other systems. A well-designed third-party library should have valid default behaviors as much as possible, and can work with minimal configuration. The contact area of the integrated code should be minimized (the larger the contact area, the deeper the contact area, the evaluation cycle and the number of maintenance work will multiply ). If a medium-level programmer has not been able to start integration for two days, the complexity of integration is questionable. (It takes more than two days to integrate the database. It usually takes n days to maintain the database)
   (In my opinion, libraries with complicated configurations and messy interfaces often mean the authorI haven't figured out how this library should be used.It is easy to identify the scenarios in which it should be used, whether or not it is covered or not exposed)

2. Memory Management. Two points of concern: A. Whether memory usage has unreasonable overhead B. Whether the memory ownership and the responsibility for allocating and releasing are clear. Theoretically, the database author should be the person who knows the best about the memory usage of the database. He should customize clear allocation and management policies. When the budget is exceeded, users should be clearly notified to have the opportunity to handle such incidents, rather than assigning the resources as much as they want. (A better design is to design the memory usage to be scalable, so that the caller has the opportunity to dynamically specify the memory usage as needed during runtime)
   If a database cannot manage an independent heap or memory pool independently, at least open the alloc/free interface. (In this way, you can take over at least and have the opportunity to decide whether to forward data to the System Heap or custom heap and insert some statistical and debugging code.) The worst case is that, new/delete directly everywhere. In this way, it is difficult to control the resource consumption.

3. Handle a large number of I/O accesses. The hard disk, CD, and network are all delayed, so the access policy is very important. A third-party library should never directly call system APIs to access external resources (such as sound files). The caller should have the opportunity to capture file and data requests and provide customized solutions, read data from custom data sources (such as packaged data cached in memory. The most flexible way is that the library does not provide any file or stream reading at all. It only accesses the given memory block and gives the caller developers the complete way to obtain the resources. The worst middleware always assumes that the POSIX file system is effective on the target platform and relies directly on files and fopen () during the C language runtime.

4. Log System. A well-designed library can handle runtime messages, warnings, and errors in a consistent manner, and can be easily integrated into your existing log system. A better design gives you an option to enable various types of information from high to low (from completely silent to the minimum number of critical errors to complete debugging information. When the silent option is enabled, the additional debugging output strings can be eliminated during the compilation period to avoid additional overhead. When 'noisy verbosity 'and other options are enabled, various system indicators are constantly output. Through a given output segment, the context details of the system running at that time can be basically understood, improper use can also be captured in a timely manner.

5. Error Handling, stability, performance overhead, and tools. Generally, evaluating a technology is a must-have indicator. I will not go into detail here.

6. Customer support, maintenance workload, portability, and so on. These extended requirements are all intuitive and will not be mentioned.