Re: alternate simplified proposal #1
Parkson Wong (parkson@nas.nasa.gov)
Tue, 11 Jun 1996 10:06:07 -0700 (PDT)
>
> Parkson writes:
> >Info (the new word for hints) is just a hint. We can't expect all
> >implementation to do something with it, so moving the directives from
> >the filename to info has quite different semantics.
> >
> >In the original spec, if you open piofs:/foo, and that system does not
> >support piofs, an error will be returned. (It may not have specified
> >that way, but it is the intent of the spec.) If this is in the info, it
> >is just ignored.
>
> 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?
>
> 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.
>
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
--
Parkson Wong Address: Numerical Aerodynamic Simulation
MRJ, Inc. NASA Ames Research Center M/S 258-6
Supercomputer Applications Segment Moffett Field, CA 94035-1000
e-mail: parkson@nas.nasa.gov Phone: (415)604-3988 Fax: (415)966-8669