Re: [Boost-users] Subject: Formal Review of Proposed Boost.Process library starts tomorrow

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