Is there any interest in a library for Application System? (Request for comments)
Some detail (Brainstorm): This library will provide a simple way to create an application that can be: . 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. Some type of "system global mutex" will be implemented in this flavor, then if user want, he can determine that only one instance of service will run in a system in same time. A web server, data base server and so on area examples. . A Usual Application A usual application is a normal application, that don't need all of features provided by "server application" usually is started by a user and run by a determined period. A command, mail client, MPI master/Slave and so on area examples. . Base Class Both classes will be derivated of environment class that will provide common thinks and proprieties like an "app path", "app name", "app work dir" and so on. For sample: A user that want create a server, extend your class of "server class" and then override methods that want to get needed behavior. // 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{}; Note that: 1) Application can be configured using Boost.Program_options 2) I want use Boost.Log to provide log functionality when available. 3) I want create a "service model" then I want use Boost.Extension to provide dynamically late bind extension (Pluf-in System). What Boosters think? This is useful or is fool lib? Boosters think that "this kind of lib" is very specific, and violate: "The library must be generally useful and not restricted to a narrow problem domain." or this kind of system is relevant to boost. Please let me know the correct way to follows! Please make suggestions! What more else? Thanks
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.
Hi, Thanks again! I will start a prototype, and I will consider yours comments. I will get back when have something more concrete. Thanks :0) -----Mensagem original----- De: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] Em nome de Jarrad Waterloo Enviada em: quinta-feira, 5 de janeiro de 2012 12:17 Para: boost@lists.boost.org Assunto: Re: [boost] Is there any interest in a library for Application System? (Request for comments)
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. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (2)
-
Jarrad Waterloo -
Renato Tegon Forti