On Sep 19, 2008, at 11:31 AM, Supalov, Alexander wrote:

I don't think taking advanced interface discussion to another list will help that interface in the end. However beautiful the result will be, until it's blessed by the Forum, it'll have fundamental handicap.

If that's practicable, it would be better to draw the OOMPI and Boost MPI C++ into the fold and finally drive into the standard something that looks like a good C++ interface for MPI. Same with Fortran.

There was significant resistance to this idea in 1995-6 -- it's the reason that OOMPI was not blessed as the official C++ MPI bindings, and instead, we went with bindings that are pretty much a 1:1 match for the C bindings. The reason is that OOMPI / Boost.MPI / etc. add different definitions and semantics over the bottom layer MPI bindings. As such, it's basically a different communications package -- it has [sometimes significantly] different rules and behavior than "core" MPI. Putting this stuff in the MPI standard was not seen as suitable because it effectively defines a new/second MPI standard that is specific to a single language. I still agree with this decision. Instead, the idea is to provide building blocks in the bindings, and provide enough hooks for upper-layer library and language authors to be able to do whatever higher-level concepts they want to do (like OOMPI, Boost.MPI, ...etc.). Remember that one of MPI's primary objectives is to be a foundation for higher-level libraries. I think that the same ideas would also be appropriate for an advanced Fortran MPI library -- use some of the power of the language to do things that a) programmers of that language expect (e.g., avoid requiring specifying the MPI datatype when it's easy/cheap for the library to figure it out itself) and b) are outside the scope of the definitions that MPI provides. FWIW: bringing these libraries under the umbrella of the MPI Forum (even if they're not in the One True MPI Standard) may be difficult because of the nature of the communities that develop them. Boost is a huge community with its own set of rules, guidelines, and goals -- they're not necessarily the same as the MPI Forum's rules, guidelines, and goals. All that being said, I do understand your point of "if it's not in the [or "a"] standard, it'll prevent wide adoption." -- Jeff Squyres Cisco Systems