Factor-out library #17
Description
To make reuse of this project possible and convenient we need to split it into a library and a sample server. The library would be the project core, the part that can be used in other projects. The sample server would be an example of the library usage. Compilation of sample server should be optional. E.g. cmake BUILD_SAMPLE_SERVER=ON.
I see two problems on the way of turning the project into a lib:
- The boundary where we cut sample server from the lib. It would be the API of the lib.
- Customization mechanism.
Speaking about the API, I can say that most of our interfaces (defined in the headers) are already good enough to serve as the API. The real question goes mainly about server.h. Should we include it in the lib or should we put it into a server sample? First of all, it is totally possible to use the lib without the server.h by making one's own server. On the other hand, server implementation is common, so it would be nice to have it as a default high-level API. So here we would have two options for our users: either use our server.h or make their own.
The customization problem arises from the reuse of our server.h. And the problem here is to make possible for users to build responses without changing our sources. Currently we have Server::makeResponse, a private method which produces responses for RADIUS requests. It is good for testing but useless for the API. We need a way to allow users of the lib to provide their own implementation for Server::makeResponse. And we have at least two possible mechanisms to do it:
- Virtual methods.
- Callbacks.
If we go with virtual methods, the users of the Server would need to inherit their own class from it and override pure virtual Server::makeResponse, providing their own implementation for it.
If we go with callbacks, the users would need to provide a callback (likely as a parameter of the Server constructor) which will be called on receive instead of Server::makeResponse. We can use std::function with an appropriate signature for this purpose.
There are advantages and disadvantages for both ways, so we need to consider both possibilities.
The other problem regarding customization is logging. For now we use simple std::cout in different places. We need to ditch this cursed practice in favour of some better logging mechanism. Some uses would not need any logging (and it is bad for them to see unexpected output from the lib), some users would not have a std::cout (servers, embedded applications) and would need some other way to put these messages. So we need to provide some flexibility here as well. Either by virtual methods or by callbacks. Also we need to remove all debugging output from places that are not expected to produce logs - like Packet or Dictionary or Attribute.
In short, here is a list of things to do: