Hi All, There is no intersection in functionality between proposed boost::process and boost::application. Boost::process defines portable interface to process abstraction, for example: start, wait, set environment variables, communicate via pipe... It simplifies use case when parent process controls child process. "Process abstraction" in this context means "operating system process". Boost::application is not about relationships between OS processes. It defines abstraction of an application. Renato has posted an article ( http://www.codeproject.com/Articles/756866/Build-a-Server-Application-using-... ) which is good example of what can be done using boost::application but it shifts the focus to server side development. I even saw one confused comment asking why this library is called "application" but not "service" or "daemon". In fact the name of the library is chosen very well. There are different kinds of applications: services/daemons, console applications, GUI applications. There are also pluggable modules of different kinds. And there are not that many things that all these applications can share to be called a library. However they have some similarities: 1. Any application needs to be started; 2. An application works in its own environment; 3. An application should be initialised using configuration taken from the environment; Basic facilities provided by C++ implement these 3 points in the following way: 1. Starting point: function main(); 2. Environment: arguments of function main(argc, argv) and ::getenv from <cstdlib> 3. Initialisation: constructors of global objects and the beginning of function main(); These are facilities that came to C++ from C language and any mature C++ project implements its own abstractions on top of these basic interfaces. Boost::application plays a role of framework that helps developers to define these 3 points in the way required by their particular application. It also provides two cross-platform templates for console application and server side application (the author uses term "application mode"). For those who don't like frameworks (e.g. me) - the good news is that boost::application is extendable framework. In the core of the library there is Aspect Map which holds application environment in general way. Possible competitors of boost::application are classes like QApplication but boost::application doesn't impose predefined set of application properties (and application types). There is one obvious conclusion - if you are working on legacy or stable project you might not need boost::application. Possible audience that can benefit from boost::application is development team who have just started a C++ project and they don't have their own application framework. They can chose one of the "application modes" provided by boost::application and quickly pass the initial phase of the project. Later when they find that their application requires some special configuration and/or initialisation they can add it by modifying their "application mode". Questions that can add more justification to boost::application: 1. How long does it take for you to implement function that returns full path to application executable (using std:: or boost:: facilities)? 2. Can you properly daemonize a process? 3. Those who answered "yes" on second question - can you register a Windows service? Thanks and regards, Alexey Tkachenko. On 21 Apr, 2014, at 1:25 am, Klaim - Joël Lamotte wrote:

On Sun, Apr 20, 2014 at 6:29 PM, Niall Douglas wrote:

...

Sure, I got that, but from the 90 seconds I looked at your docs it wasn't clear to me why you appeared to be replacing instead of extending Boost.Process. Of course you may not be replacing, but that wasnt't obvious in 90 seconds of looking.

Just to be clear Niall, the part that you think is common to Process is basically the server/daemon setup feature, am I right?

Because, my understanding of Application is that it's closer to a customizable ready-to-use scafholding or "template", to quickly setup a correct daemon(or not) with dynamic plugins. Assuming that Boost.Process does provide in the future a way to setup the daemon side of the application, then Application would indeed use Boost.Process inside, like it already does with Boost.ProgramOptions.

I think your advice of submitting several small libraries was already given when Boost.Application was first introduced to the list. Basically, process configuration (boost.process), dynamic plugins (boost.extension) and command line interpretation (boost.program_option) are clearly libraries I would like to see in boost and have been using in non-released forms before (except the last one). Boost.Application is interesting because it looks like a useful abstraction around these and that make me think that it might be useful to make the user ignore what is used inside Boost.Application so that the implementation can use the mentionned boost libraries inside when they are stable enough. What I mean is: wouldn't it be possible to review the Boost.Application interface and current implementation but assume that the parts that should be part of Boost.Process/Extension will use these libraries once ready? I think this happened several time before (maybe in Boost.Log) where the implementation did something already available in other libs but not good enough yet, and the implementation was rewritten when the official library was ready to replace it (boost.atomic was discussed this way for several libraries if I remember correctly).

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost