> If the MPI Forum has rejected the idea of stuffing resource-related
> information in strings then we cannot use file names. A file name is a
> string and it specifies resources which include a file and data in the
> file. If we do decide to use info args, then we should use a {file,
> name} pair for file names.
Oh, not really. A computation is embedded in a space of these
coordinates:
Data Set(s)
Method(s)
User(s)
Resource(s)
Finding suitable bindings for states in this system is the task of
software engineering.
> I think this points to a fundamental issue that was not resolved at the
> last meeting. What do we want MPI-IO to support? I want MPI-IO to be a
> file interface.
This is simply too limiting for network computing. Data-mining
applications need to work with local disk and remote I/O servers
in the same run.
> Your connect call is similar to a mount. However, I believe connect is
> more general. Do we want this functionality within MPI-IO? The NFS
> procotocol consists of the mount protocol and file access protocol.
Try asking the management at your site to mount disks at Nasa Ames.
Then try asking Ames for permission ...
Further, consider trying to mount a remote I/O server. The inode paradigm
breaks down at this point.
> Do
> we want to roll both into MPI-IO? If so, shouldn't we ask people what
> they want to support and figure out if info args are adequate?
Well, I thought I was a person ... Others at the meeting are checking
with their {\em users}.
- Richard