Some detail (Brainstorm): ...
. A Server Application
A server application usually starts when system boot, and then remain running as background process, don't matter who is currently logged.
In Windows this will a "Windows Service" and in UNIX a "UNIX Daemon", and we can create a "Neutral Application" that is not a daemon and service, but uses "service interface" that will provide methods like an "init", "interrogate", "restart" and so on.
...
// windows service, or daemon class myapp : public boost::application::server{};
// neutral server class myapp : public boost::application::server<neutral>{};
// usual application class myapp : public boost::application::app{};
Consider using a single base class instead of three such that one can choose how it is started from the command line parameters or configuration file. It is common to debug as a usual application and deploy as a service/daemon. Other work needed to be done are as follows: 1) int main(const vector<[w]string>& parameters) member function where the developer puts his code. This provides converting of const char*[] parameter to the standard main function. 2) creating a windows service blocks the main thread so the above step#1 main function would need to be called from a new C++0x/boost thread. 3) control C signal handlers for terminating the service constructively 4) char versus wchar versus utf8char versus utf32char debate; the latter pseudo types are the new char types supported by C++0x 5) since this library needs to be general and boosters would want to use their own command line parameter or configuration file mechanism, though a smart default is welcome, the base class may need to be abstract asking the user defined application class enum isDaemonNeutralOrUsual(); which would have to be virtual which boosters hate even if this is the only class instance in the application or the compile abstract trick of class MyClass : public boost::application:server<MyClass>{};// class inheriting from base that inherits from itself The first three items are features already provided by the POCO library. The fifth is to make things more general for those who want a configuration file capable of return objects instead of just strings.