massive rewrite, splitt LibMsgque into theLink, theConfig, theBrain, theGuard and theCompiler.
massive rewrite, splitt LibMsgque into theLink, theConfig, theBrain, theGuard and theCompiler.
Actually, the problem was quite simple, the libconfig library should be integrated into libmsgque in order to ultimately support not only the command line but also a configuration file.
The integration also ran smoothly and after about 1 week the functionality was available internally.
Now the question was how to proceed, especially since the user may need to use the libconfig library separately, i.e. ultimately independently of the application server. Of course, the new functionality should also be integrated into all programming languages in order to ultimately get the same support as libmsgque.
From now on the problem escalated !!
In short, a tsunami of new technology was required because the monolithic application libmsgque had to be broken up into small parts in order to ultimately be able to offer each functionality individually.
I call this kernel split
Anyone who has ever splitted a monolithic application knows the problem
finally the project was a complete rewrite of the essential functionality not only in the application server but also in the whole toolbox including compiler / backend / automake etc
In the end, a lot of new packages were created as sub-projects for NHI1
link | package |
---|---|
theKernel | A library that adds an object layer with language bindings to the C language |
theLink | A library to connect things, run a server and integrate your application |
theCompiler | A tool to parse and understand header files (API) and then generate new code in a desired target language. |
theConfig | Support the libconfig native library |
theBrain | A tool for adding database support to a project |
theGuard | A filter who protects the communication by encrypting the data stream |