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

Subject: Re: [Boost-users] Brainstorming [WAS: Subject: Formal Review of Proposed Boost.Process library starts tomorrow]
From: Ilya Sokolov (ilyasokol_at_[hidden])
Date: 2011-02-11 00:54:04

On Fri, 11 Feb 2011 06:01:56 +0500, Boris Schaeling <boris_at_[hidden]>  
wrote:

> As development of Boost.Process started ages ago and it seems like we  
> still don't get anywhere I'd like to ask why this is so. I do see very  
> valuable feedback every time Boost.Process is discussed. But at the same  
> time some concerns are raised again and again no matter how much the  
> library was changed since the last discussion.
>
> So here's my attempt to explain why we struggle so much:
>
> As Boost users we want platform-independent code and convenient  
> high-level interfaces. As C++ developers we want efficient  
> implementations and flexibility. It seems like as if these goals are  
> contrary for a process management library. And in my opinion the very  
> different system interfaces are the main reason. If Boost.Process has  
> platform-independent code only, developers will complain about the lack  
> of flexibility.

Such library would be practically useless, so it's no-go.

> If Boost.Process provides flexibility with Windows and POSIX APIs,  
> developers will complain about #ifdefs and writing code twice.

I would call system functions directly, instead.

> If Boost.Process supports high-level concepts, developers will complain  
> about inefficient implementations.

I suppose you had 'async wait' feature in mind. Give such developers
a choice to not use 'high-level' concepts.

> If Boost.Process supports only what can be implemented cross-platform  
> efficiently, the library is so small that it's practically useless.

No-go.

> And if Boost.Process supports a compromise like generic code with  
> extension points, developers from both sides will complain about not  
> generic and flexible enough.

It's ok ).

> Could it be that goals are too different?

I believe that there are just many false goals.

> Do we need multiple Boost.Process libraries? Boost.ProcessForWindows,  
> Boost.ProcessForPOSIX, Boost.ProcessForEveryone? Back to generic  
> classes, Windows classes and POSIX classes? Efficient implementations  
> but very few features in the generic classes and very different APIs  
> between the Windows and POSIX classes? If this sounds good does it help  
> anyone?

No on all of the above questions.

> Would you use such a library or simply call system functions directly?

The latter, that's why I answered no above.

> After all it's not that difficult to create a child process without a  
> library and you would get full flexibility without an extra layer from a  
> library?
>
> Comments greatly appreciated!
>
> Boris