Bottom-up approach for building GLog module

The main objective of gUtil layer is to standardize the approach for completing similar tasks, where the initial idea is by having a thin wrapper that centrally simplifies and controls the interfaces for accessing various third party libraries. By accomplishing this, Netcom Simulator project is hopefully will be able to progress faster in future, yet making maintenance easier.

Now, there is a significant challenge while developing its GLog module. The fundamental logging concept of those libraries is more or less the same. However, their implementations as well as way for using them could be vastly different, in one aspect or more. Configuration (a.k.a. initialization) of logger is a good example.

For this reason, I just decided to try out bottom-up approach in developing GLog module (and other modules in gUtil as well). Instead of study all the common logging libraries then build GLog module base on the result, I will implement the bare minimum features by hand without relying on those logging frameworks (though might borrow some concepts from them). From there, I can gain more in depth understanding on the most common use cases for logging (and how it works). While the project’s needs evolve, I will slowly evaluate and see which one of them will better fit the project needs, thus my implementation might be progressively replaced by utilization of third-party logging framework. Throughout this process, I will try to keep the GLog module as compatible with those third-party libraries as possible.

As a side effect, this strategy may affect the scope of gUtil layer. Eventually gUtil may not be as “thin” as what had been planned initially. However, this change should be worthy in gaining progress for NetCom. I hope this strategy will not introduce too many major versions of gUtil’s modules, as each major version itself is a sign of compatibility issue.

Comments are closed.