Re: [boost] Application need a Review Manager. Anyone is interested?

Subject: Re: [boost] Application need a Review Manager. Anyone is interested?
From: Klaim - Joël Lamotte (mjklaim_at_[hidden])
Date: 2014-04-20 13:25:28

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