Re: alternate simplified proposal #1

Richard Frost (frost@sdsc.edu)
Tue, 11 Jun 1996 11:06:28 -0700 (PDT)

> A hint is a hint, so it cannot change the semantics of the function call.
> That is why it does not belong to the hint. It could only hint that it
> is a piofs file, but it can't enforce it. I think this is not well defined.
>
> So, if you want a separate argument to do this, fine, but it cannot be put
> into hint (or info). I still think encoding it in the filename is fine
> unlese someone come up with some good argument.
>
> -- parkson

The "hints" or "info" structure is a way to provide extensibility
to the MPI API. It also allows vendors to meet the requirements of
the standard while only supporting the features which are economically
feasible. Some vendors could care less about piofs or anything besides
local disk. Why force them into parsing an encoding of a resource from
a data set (file) name?

Meanwhile, other developers would like to allow their MPI I/O file handles
to work on piped standard input and arbitrary sockets.

A mechanism is also desirable for specifying resource access patterns
and local resource conditions (e.g., hint: this local disk can be used
for cache).

No standards exist in this area for the MPI Forum to build on. Instead
of trying to start N new standards efforts, we can supply "info" as
a means for researchers to experiment with new computational paradigms.

- Richard