Re: interoperability and metadata [was: Proposal for better ...]

Jean-Pierre Prost (JPPROST@watson.ibm.com)
Thu, 24 Oct 1996 16:56:28 -0400

--0__=0foFGVoN4rzhXaUsnsHw3OeFB4RM5aDa2PFJa6IXtXetLCWJ8KtRDjOa
Content-type: text/plain; charset=us-ascii

Do not take my comments as destructive, I wish I had a constructive
suggestion to make. And I do not suggest to delete the section. On the
other hand, I am glad you are trying to address this difficult issue.

With regard to votes, I agree we ruled out self describing files.
However,
introducing an embedded file header for encoding the data representation
and architecture information of the file data is very different from and
not as
ambitious as having self describing files.

Embedded file headers do not resolve everything, but at least they
it allow file interoperability without requiring from the user the need
to remember where (s)he has stored the data representation of the
files (s)he had created.
Embedded file header (of fixed size) have the advantage to be highly
portable across file systems and are self contained. I agree they
may present some problem for legacy applications that expect
standard UNIX files, the reason for making them optional on a per
file creation basis. Nothing is perfect in our world.

Jean-Pierre

---------- Forwarding Original Note --------
To: JPPROST
cc: mpi-io @ mcs.anl.gov
From: frost @ sdsc.edu
Date: 10/24/96 01:43:10 PM MST
Subject: Re: interoperability and metadata [was: Proposal for better ...]
Security:

--0__=0foFGVoN4rzhXaUsnsHw3OeFB4RM5aDa2PFJa6IXtXetLCWJ8KtRDjOa

> Creating a header file in this framework is straightforward:
> - write the buffer from MPI_FH_ARCH_ENCODE
> - write the buffer from MPI_(DATA)_TYPE_ENCODE for each view +
> the offset of that view.
> The first part is quite easy. However, the second part is pretty complex.

I agree with your assessment. We will try to define a mechanism that
works in a few straightforward cases.

Perhaps others will volunteer some constructive suggestions?
(Other than delete the section!)

> PS: I would prefer that you do not rule out the possibility of an
> optional embedded
> header right away, before this issue is discussed at length at the next
> MPI forum in
> January. The idea of a separate header file does not seduce me too much.

I personally like embedded headers. There have been some strong
arguments to the contrary. Also: note that IF you embed a header with
architectural and datatype+filetype information, then the file is
self-describing!
Well, we voted that out so apparently we have to have a separate metadata
file or change our vote.

- Richard

--0__=0foFGVoN4rzhXaUsnsHw3OeFB4RM5aDa2PFJa6IXtXetLCWJ8KtRDjOa--