I don't disagree with your historical observations, but I
draw a different conclusion from them. We have spent many
months deciding what functionality we want and understanding
the issues in great detail. The draft of the last meeting
reflects this historical process and is (to some) a confused
jumble of functions, each one targeted towards a different
piece of functionality. It is only now, after having gone
through the whole process that we are able to step back
and make sense of what has been produced. The counter-proposal
does that. It is not a departure, but a reorganization designed
to clarify and unify.
> Those who want to reduce the number of functions should vote out the functions
> that supply capability for spawning independent and non-MPI processes, or vote
> out the ability to spawn multiple executables, or vote out MPI_Spawn as a
> convenience function for the special case of MPI_Spawn_multiple. I'll vote
> for them, but I don't mind if I lose on these issues.
If (and only if) there is strong support for the counter-proposal,
proceeding with votes on the current proposal would be a waste
of time. It is appropriate if the debate is over functionality,
but the counter-proposal provides the same functionality
with a very different set of functions. As someone who has
criticized MPI-1 for its bloat, I want to make sure that
we give ourselves a chance to step back and see the big picture
before locking the historical record into a standard.
Bill