I think that we need enough data to put the constants into classes of constants that are different from one implementation to the other (examples for a classes, are "handles", "datatype"). Once done, we'll be able to understand the differences in the different implementations (approach) and in the different platforms. This will enable us to come up with reasonable suggestion for the ABI constants. I think that putting the constants in different spreadsheet (split by os/cpu) is reasonable. Thanks, .Erez -----Original Message----- From: mpi3-abi-bounces_at_[hidden] [mailto:mpi3-abi-bounces_at_[hidden]] On Behalf Of Jeff Squyres Sent: Friday, April 25, 2008 7:04 AM To: MPI 3.0 ABI working group Subject: Re: [Mpi3-abi] For the April MPI Forum Meeting On Apr 25, 2008, at 8:32 AM, Supalov, Alexander wrote:

The purpose of having as much input data as possible before deciding whether and how to proceed is to not miss a potentially important data point.

In this vein, I'd love to see some MPICH1 and HP MPI data there. That, with the data already in the spreadsheet, would most likely cover 99% of the currently targeted platforms (IA32/Intel64/Linux/Windows).

I'm all for having enough data points. I was questioning how many we need -- it just looked like we we diverging into the "need dozens of datapoints" realm. If we're not, no problem.

A split into several files would make sense if we had dozens of actively contributing members. At the moment we are blessed with but a few.

The wiki has no "lock" feature. SVN does, but we don't really have a common SVN. This is the canonical problem with binary formats -- more power in the binary-based tool (excel), but less collaboration ability. I suppose a sharepoint server would work...? But [I'm assuming] that would be a nightmare of licensing and access control setup. We could use a tex-based format (latex?) that allows merge capabilities, or use the wiki text format (but wikis don't handle simultaneous editing nicely -- someone inevitably "loses", rather than having the ability to merge their new text in). Splitting into mutliple files, each with a discrete author, might still be the best solution. [shrug] -- Jeff Squyres Cisco Systems _______________________________________________ mpi3-abi mailing list mpi3-abi_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-abi