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: Jeff Flinn (TriumphSprint2000_at_[hidden])
Date: 2011-02-11 10:39:35

Boris Schaeling 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. 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!

I think with the right abstractions the seemingly contradictory goals 
can be accommodated. That's what I'm attempting to find. As stated at a 
previous boostcon: "... abstractions are discovered not invented..."

IMHO, previous version of process have not discovered the proper 
abstractions. I'm sure that the entirely different paradigms between 
windows and posix have contributed to the difficulties so far. It's 
difficult to be a master of the subject matter in both domains.

I think building upon existing boost filesystem and iostreams libraries 
and their abstractions that do successfully address platform differences 
will make the effort more successful. Additionally I think it's 
mandatory for a design to directly acknowledge the multi-phase 
constraints of the fork/exec paradigm. Also it's mandatory to break down 
the historical monolithic approaches into more tenable pieces.

Just my 2 cents,

Jeff