Thanks for the quick feedback!
The first problem, heterogeneous instantiations of
> struct test {
> int i;
> char c;
> int j
> };
is something I would expect a "smart" implementation to handle. For
example, current implementations already perform exceptions when 32/64 bit
conversions are necessary. Is it hard to recognize heterogeneous
connections and perform careful placement? After all, the datatype is
available. I would go so far as to make it part of the MPI spec.
Otherwise, vendors will link their libraries against a version which fails
on heterogeneous transactions. I've already watched Express and PVM fail
at this. Express fixed their problem, but it was too late for 3rd parties.
Please take this issue seriously. For our project and many others, ARPA
has mandated that we consider interchanging software and hardware
architectures. So with regard to heterogeneous compatibility among MPI
data types, you would serve ARPA's mission well by defining a spec which
enables interoperable digital library technology.
> A question about the attribute string: Is the intention that when you
> decode a datatype that the attribute stay with the datatype?
Yes, very much so. What interests clients most is context. It
is a mechanism for data producers to indicate what the contents of
a particular type represent: is it a collection of various GIS data,
a system matrix for a certain simulation, or perhaps this struct
defines a chemical molecule with the 1st element being ...
There are of course many existing lexicographies for labeling
data elements. In my view, it is application specific. In fact,
most application areas have a rich set of key codes; e.g., GIS.
So for example if my parallel application discovers a rich data
store of Tampa Bay data, then retrieves the datatypes and finds
there are elements which it can process, it can then instantiate
the types and process the data. Consider this a heterogeneous
transaction: the data might have been originally stored by one
system and is now being read by another. Even worse: the data
server is on a third architecture.
Richard Frost
SDSC