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

Subject: [Boost-users] Brainstorming [WAS: Subject: Formal Review of Proposed Boost.Process library starts tomorrow]
From: Boris Schaeling (boris_at_[hidden])
Date: 2011-02-10 20:01:56

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. If Boost.Process  
provides flexibility with Windows and POSIX APIs, developers will complain  
about #ifdefs and writing code twice. If Boost.Process supports high-level  
concepts, developers will complain about inefficient implementations. If  
Boost.Process supports only what can be implemented cross-platform  
efficiently, the library is so small that it's practically useless. 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.

Could it be that goals are too different? 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? Would you use such a  
library or simply call system functions directly? 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