Re: alternate simplified proposal #1

Richard Frost (frost@sdsc.edu)
Mon, 10 Jun 1996 16:39:32 -0700 (PDT)

>
> I'm confused by your example. Let's say an implementation does not
> support piofs. If a user tries to open a piofs file with info
> args--hints what does open() return? Shouldn't open() return an error
> because the implementation does not support piofs?

Yes, it would return an error.

> I asked Richard for examples because I would like to know what he wants
> to support with info args. While the file name space has limitations,
> it is simple, well-known, and can support a lot of abstractions.
>

Here's some background on my "info" proposal:

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.

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.

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.

- Richard