Only 8 more days and SoC will be officially over... Time has passed very fast and my project required much more work than I initially thought. It certainly cannot be completed before the deadline but I assure you that it will not fall into oblivion afterwards; I have spent too much time on it to forget ;-)

There have been many changes in Boost.Process' code base since the previous status report; let's see a brief summary:
  • The library has been simplified removing all those bits that were aimed at "generic process management". Now it is focused on child process managing only, although extending it to support other process-related functionality is still possible (preserving compatibility with the current API). It'll be better to design and implement these features when really needed because they will require a lot of work and cannot be planned right now; doing so might result in an incomplete and clusmy design. Yup... my mentor (Jeff Garland) was right when he suggested to go this simplified route at the very beginning!
  • Due to the above simplifications, some classes are not templated any more (the stuff that depended on the template parameters is now gone). I bet some of them could still be, but this can be easily changed later on.
  • There is now a specialized launcher in the library to painlessly start command pipelines. This also comes with a helper process group class to treat the set of processes as a unique entity.
  • The user now has much more flexibility to specify how a child process' channels behave. While documenting the previous API it became clear that it was incomplete and hard to understand.
  • Code from all launchers has been unified in a base private class to avoid duplication and ensure consistency across those classes. Similar changes have ocurred in the test suite, which helped in catching some obscure problems.
  • Related to previous, many of the code used to do the actual task of spawning a process has been moved out of the individual launcher classes into some generic private functions. This was done to share more code, improve cohesion and readability.
  • The documentation is now much better, although it still lacks a chapter about design issues. See the online snapshot for more details.
  • And, of course, multiple bug fixes and cleanups.
Still, I haven't had a chance to ask for a public review in Boost's developers mailing list. The problem is that I continously find things to improve or to complete and prefer to do them before asking for the review. However, as time is running out I'll be forced to do this in the forthcoming week to get some more feedback in time.