So info args are not hints. Sorry, I took Parkson's message (info args
== hints) literally.
>1. The Forum has already rejected the idea of stuffing resource-related
>information in strings. Instead, a key-value structure has been defined
>by the mpi-dynamic working group.
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.
Personally, I don't like the idea of info args because I don't think we
need them. I like file name spaces. Simple mind, simple pleasures I
guess.
>2. The Newcastle encryption would still require a set of string
>manipulation tools, both on the user and implementation side. Consider
>the burden for Fortran programmers.
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. A user accesses files normally found in a file name
space. I agree that this is very simple, but IMO the functionality file
name spaces provide is sufficient. I don't know anything about
Newcastle encryption, but I assume it is an example of an abstraction
that will not fit into a file name space well. Do we want to support
it?
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. 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?
>3. When the alternate resource is remote, the user will need to specify
>it in the info argument (for FCONNECT, not FOPEN). But what about the
>case of two servers: one local and the other remote but otherwise
>identical in functionality. The file name space mechanism would require
>a string pre-pended to the file name for the local server. For the
>remote server, connection info would go in the info argument and there
>would be no pre-pended info in the file name. I'd really hate to have
>two mechanisms to do essentially the same thing at two different sites.
>I'm much more comfortable with the separation of file (or data set)
>names and resource location.
With the current MPI-IO standard, I would handle this case with whatever
the file name space gives me. For example, on the Cenju-3 we use NFS to
access remote files. This means using /net/machine for the remote file.