Date: Fri, 18 Jun 1999 08:35:14 -0700 (PDT)
From: Linda Stanberry <linda@XXXXXXXXXXX>
To: mpi-core@XXXXXXXXXXX,treumann@XXXXXXXXXX
Subject: Re: Request for interpretation
Sender: owner-mpi-core@XXXXXXXXXXX
Precedence: bulk
X-UIDL: 011fb9581cb2ba84823f60375f80dc39

The IBM implementation of MPI_Info is, in my opinion, extending the
semantics of MPI_INFO_SET and MPI_INFO_GET beyond what the standard says.
I do not find in the specifications of these functions that they are
supposed to behave as filters to determine what hints are accepted or
to modify the values associated with keys that are recognized, nor to
behave in the way that MPI_FILE_GET_INFO was intended to provide feedback
on which hints were recognized/effective for a given file.

As I said in my earlier example, this interpretation prohibits layering my
own MPI-IO over this implementation, unless I also provide my own MPI_Info
functionality.  But this could wreak havoc with the MPI_Win implementation
if my MPI_INFO_SET did not scale the IBM_framus_size, for example, to a 
value in the 0-10 range; either an error will result from using an unscaled
value, or there will be duplication of effort in MPI_WIN_CREATE to do the
scaling/checking of the Info values.

It seems to me that if the same functionality that MPI_FILE_GET_INFO
provides is desired for MPI_Win objects, there should be an MPI_WIN_GET_INFO.
If the MPI_Info implementation does not restrict the key/value pairs, as I
believe it should not, then MPI-2 is extensible so that an MPI_WIN_GET_INFO
or an MPI_WIDGET_GET_INFO can be provided as an extension to the standard,
and prior art for MPI-3.

Allowing the extensibility and layerability is in the better interest of
all users, and permits a means to provide the desired enhancements that IBM
wants to provide for its own users.

Linda
lstanberry@XXXXXXXX