Re: [Boost-users] [C++ Now! 2012] Call for Submissions

Subject: Re: [Boost-users] [C++ Now! 2012] Call for Submissions
From: Nat Linden (nat_at_[hidden])
Date: 2011-11-10 10:12:34

On Wed, Nov 9, 2011 at 6:37 PM, Boris Schaeling <boris_at_[hidden]> wrote:

> On Mon, 31 Oct 2011 17:24:28 +0100, Nat Linden <nat_at_[hidden]> wrote:

>> On Sun, Oct 30, 2011 at 10:26 AM, Hartmut Kaiser
>> <hartmut.kaiser_at_[hidden]> wrote:

>>> INAUGURAL C++ NOW! CONFERENCE 2012
>>> Aspen CO, USA, May 14-18, 2012, www.cppnow.org
>>>
>>> SESSION FORMATS
>>>
>>> Workshops         Workshops provide an active arena for advancements in
>>>                 Boost-relevant topics. Workshops provide the opportunity
>>>                 for experienced practitioners to develop new ideas about
>>>                 a topic of common interest and experience.

>> Correct me if I'm wrong, but my impression of current library status
>> is that Boris brought forward a proposal -- which generated a round of
>> controversy -- which ended in more or less a stalemate.

> We left BoostCon 2011 with the goal of creating another Boost.Process draft based on Jeff Flinn's ideas. The draft can be found online at <https://github.com/JeffFlinn/boost-process>. You don't really need to click on this link though as there haven't been any changes since June. :)

Ah. Well, let me generalize my request: whatever the current state of
Boost.Process, I'd really like for us to collectively take the
opportunity of C++ Now to push it further forward.

> I worked on <https://github.com/BorisSchaeling/asio> to add an asio::windows::object_handle class to Boost.Asio. This I/O object can be used for all kind of object handles - including process handles. As Boost.Asio ships already an I/O object for signals, it will be possible then to wait asynchronously for processes based on platform-specific concepts developers are familiar with and feel natural to use on Unix and Windows.

Hmm, okay. That isn't specifically interesting to me. Full disclosure:
I want Boost.Process to provide a portable way to run a child process,
both synchronously and asynchronously. (I personally would be content
with a conceptual model resembling that of Python's subprocess API.)
That is, to me, one of the primary benefits Boost can contribute in
this space. Those who need platform-specific process-control features
can (and do) use the platform-specific API. That support exists
already. What's missing is a portable wrapper layer.

However -- that said -- if folding in asio::windows::object_handle
allows others to come to consensus and SHIP THIS LIBRARY then I'm all
for it.

> As it's some time until May and I never gave up finishing Boost.Process after all those years ;), it's maybe a good idea to work on the library from January on. If I do another Boost.Process session in May, I don't really want to repeat what Jeff and I presented last year. :) As the submission deadline is in January, I should make up my mind before that. But it's not too difficult as I should really do something with Boost.Process again ...

Whatever work you can put into evolving Boost.Process between January
and May will be wonderful. But that's not even what I'm requesting.
What I'd really like from you this May isn't so much a presentation,
but rather chairing a working session to nail down any
unresolved/controversial issues. I would be thrilled if, at the close
of this inaugural C++ Now! conference, all that remained unfinished
with Boost.Process was the implementation. I'd want us to emerge with
a solid API ready for the Boost review process, as soon as the
implementation is done.

My hope is that thrashing out any remaining controversies face-to-face
at the conference would clear the way for the email review. My hope is
that building consensus at the conference would minimize
surprising/dismaying setbacks during the review itself.