When I first start of Snap!, I had one project, the snapwebsites folder.

As I started growing the project, I wanted to have some features that required other modules such as the log4cplus library to handle logging.

The fact is that as a result the library (read: common code to all the Snap! Website services) as grown to be a really large one! Difficult to manage and each time a small change is made, we incur a long wait for rebuilding everything.

So we started working on breaking up the library in smaller parts. We already have some functional projects which now encompass some of the low level functionality of the Snap! Websites library:

snapdev

The Snap! library included many C++ header-only code which could be bounced out very easily. These are useful functions such as:

• Aa string tokenizer
• An RAII class allowing for any type of resource to be tracked without the need to specify the deleter each time you create a new instance (a drawback of the std::unique_ptr<>() existing implementation)
• The NOTREACHED() and NOTUSED() functions
• A templated Matrix class
• Etc.

snap_config to advgetopt

I moved all the snap_config functionality to the advgetopt library, making it really powerful now.

I still have a few more touch ups to do to make sure it all works in a compatible way, but my tests already verified most of that. It's just not one to one compatible (i.e. I need to create a setup dynamically for things to work, so I need an extra class which I'll add soonish, I hope.)

cppthread

This library is the snap_thread class.

In the library, I broke up the snap_thread.h and snap_thread.cpp with one file per class. As a result, the library has 20 files. Yes! It is that big! I did not add anything new except for the 2 files used for handling the library version.

The result is a one to one compatible library, only the exceptions have been tweaked to use the libexcept library and the classes are under the cppthread namespace. Also, I moved all the sub-classes as standalone classes which makes it a lot easier to manage (understand as: continue to grow).

The library also recently inherited a thread pool.

Next on the list, create the necessary to better handle a concurrency system along the snap_communicator which is now called the eventdispatcher.

snaplogger

The log.cpp and log.h were actually pretty large files too (the header not so much, but the implementation was already going at length!) However, my main problem was log4cplus. Yes. It worked. But there were many drawbacks. So I really wanted to have my own project. This is it!

This new library is most compatible with the old one. That is, I changed the () operator with the << operator because that way we can use an std::stringstream directly. This means you get all the power that this standard library class offers. For example, if you overload the << operator to work with the basic_ostream, you will be able to use that directly with this new logger. Very practical!

What else?

One of the main two drawbacks of the log4cplus were that to fork, we had to kill everything and reconfigure everything. This had to be very costly. In this new library, I just have one function call to stop the thread before a fork(). That's it. The thread will automatically be restart when you send another log message. So we killed two issues with one stone!

The one other problem I had was the setup. The file format was okay, although I did not like it that much, but it worked fine. It had many options which we didn't use, but that too was okay. What was annoying, however, is that we could not have one central setup and then various other setups depending on your application, the user, the service being run, etc. log4cplus gave you the option for exactly one configuration. This new library loads many configuration files and, especially, it supports our .d configuration scheme (just like many other Linux projects) so you can keep the default configuration file intact and only edit your own file with your own settings.

Finally, although that's much less of a drawback, the log4cplus library was not written for at least C++11. It still used std::auto_ptr<>(), for example (a deprecated template). Finally, it looks like the project is not moving forward as much as expected a few years back.

All in all, though, ours is much simple (even though it already uses 45 files) and allows for all sorts of extension to handle new appenders, the log message (variables & functions), and it's much more advanced C++ instead of old style like log4cplus. (Although I agree that we probably should make use of more templates...)

The library is also expected to be thread safe. This still has to be verified quite a bit. I've already.

Finally, I have plans to add a log service as one of the appenders. This one will allow you to send the log data through a network connection to the same computer or other computers.

eventdispatcher

This one comes from the snap_communicator.cpp/h (not the snapcommunicator service). I also included the other low level network libraries: tcp_client_server.cpp/h and the udp_client_server.cpp/h.

Mainly, this project is used to handle events and TCP/UDP socket connections in plain or encrypted modes.

The event are handled by the communicator class and dispatched by the dispatcher class.

This is pretty much a one to one move from the snap_communicator, only I changed the namespace to just "ed" ([e]vent[d]ispatcher) and I extracted all the sub-classes like I've done with the C++ thread library.

Here I did not add new files, the final library is 81 file. If we do not count the CMakeLists.txt and version.cpp/h, it's still 78 files! Yes. That one was a really large class in the Snap! Websites library. I'll be using it in another project, which is the main reason for the split up. The snapcommunicator service should be moved to this project as well, but that one is way more complicated. It includes knowledge about all sorts of services so it is ultra specialized. Still, it would be really useful to have the service as a separate project because then it could be used by any one of the low level services we develop.