On Sun, Apr 20, 2014 at 6:29 PM, Niall Douglas
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).