Subject: Re: [Boost-users] Subject: Formal Review of Proposed Boost.Process library starts tomorrow
From: Boris Schaeling (boris_at_[hidden])
Date: 2011-02-07 18:58:58
As Marshall announced that the formal review of my library has started I'd
like to provide some information which is maybe helpful for those
interested in submitting a review.
* While Boost.Process is currently my library I can't take all the credit.
Development of Boost.Process started back in 2006 and was initiated by
others. I picked up the library in 2008 and greatly benefited from the
work which had been done before. Even after 2008 other developers actively
worked on forks of Boost.Process and contributed a lot of ideas and
implementation details. I basically tried to collect and merge all the
work which was done in the past five years. (But that doesn't mean I
didn't contribute any code: I added for example support for asynchronous
operations. :)
* As development started five years ago, as we had countless of proposals
how Boost.Process should look like, as we had many developers working on
various Boost.Process drafts and even more developers contributing to
discussions on the mailing lists, it's not always easy to understand why
certain decisions were made and how we ended up with today's library.
Sometimes even I don't know - for example because I didn't write and never
touched some code (I think the class boost::process::detail::systembuf is
a few years old and has never been changed) or because we were busy
thinking about bigger problems and didn't notice some minor issues (I
think it was Vicente who recently asked why the Context parameter is not
passed by reference to boost::process::create_child()).
* We had rather different Boost.Process drafts in the past. First there
are many process management features which are unfortunately
platform-specific but still too important as if you can simply ignore
them. Second there are many features implemented in Boost.Process which
could be useful by their own. The current solution for the first problem
is that Boost.Process only supports platform-independent features and
provides extension points to plug-in support for platform-specific
features. This should make it possible to set a realistic goal of being
feature complete at some point in time and to avoid overloading the
library by trying to support too many platform-specific features. For the
second problem no solution exists. That means it's currently not easy to
use parts of Boost.Process outside of the library. For example
Boost.Process defines a class boost::process::behavior::pipe to create a
pipe. However the class is not designed in a way that it is intuitive to
use outside of Boost.Process.
* As Boost.Process tries to support platform-independent features,
designing the library comes down to identifying cross-platform concepts
and where and how to provide extension points. The implementation itself
is not that difficult. You won't find any clever C++ tricks in
Boost.Process. Compared with some of the other Boost libraries it's a
pretty normal object-oriented library. If you want to learn something new
in C++, it's probably not worth looking at the implementation. :)
* Apart from the design and implementation of the library, there is room
for improvement in the documentation and when it comes to platform
support. I had recreated the documentation in Quickbook which as far as I
know is the preferred documentation format for Boost. As I had to recreate
it, it can surely be improved and extended. As there have been changes in
the library again and again, I'm actually waiting for the right moment to
update the documentation. :) Regarding compilers and platforms: I tested
Boost.Process with Boost 1.45.0 with VC++ 2010 on Windows 7 and g++ 4.4 on
Debian 6.0 on the weekend. I'll see whether I can also support the library
on Cygwin and Solaris 11 Express (had a compiler error with Boost.Asio on
Cygwin and couldn't easily find packages for development tools for Solaris
11 Express). As some MinGW users had been interested in the library, I
also appreciate feedback for this platform (and of course for any other).
* The main reason why I proposed the library for a review is not that I
think it's all perfect. My impression though is that there is tremendous
interest in a process management library - at least that's what I think
when I look at the discussions we had on the mailing list and at the many
emails I got with questions about Boost.Process. I would appreciate more
code contributions and of course more feedback and hope that an official
Boost.Process library could foster future development.
Boris