theLink 10.0 NHI1 - theKernel - theLink - theConfig - theSq3Lite - theCompiler - theBrain - theGuard - theLib
c - tcl - atl - cs - py - rb - jv - cc
Loading...
Searching...
No Matches
28 May, 2023

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

  1. The namespace must be kicked clean
  2. The development environment (build/test/fix) must now be adjusted to a large number and individual libraries
  3. Singleton classes that span multiple libraries must be cleanly separated and expandable using a plugin mechanism.
  4. An external library such as libconfig was of course written without managed-object technology, but it still has to be able to handle it. So there must be a tool that automatically generates the managed-object code.
  5. Testing is also becoming more extensive and should ideally be automated to the extent that the user only eliminates the essential problems.
  6. An external library like libconfig naturally also has external documentation. This documentation must be read automatically and integrated into the NHI1-Doxygen documentation.

‍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