H5Part development and discussion

[Mark Howison <MHowison AT lbl.gov>]

In H5Part, we have a convention about function calls that there is a
separate call for each data type, for instance:

H5PartWriteDataFloat32
H5PartWriteDataFloat64
etc.

But for the attribute API, we are not consistent with this, and there
is a function

h5part_int64_t H5PartWriteStepAttrib    (       H5PartFile *     f,
                const char *    name,
                const h5part_int64_t    type,
                const void *    data,
                const h5part_int64_t    nelem   
        )

where the type is specified using the flags

    * H5PART_FLOAT64 (for h5part_float64_t)
    * H5PART_FLOAT32 (for h5part_float32_t)
    * H5PART_INT64 (for h5part_int64_t)
    * H5PART_INT32 (for h5part_int32_t)
    * H5PART_CHAR (for char)
    * H5PART_STRING (for char*)

At some point, I created functions for each type:

H5PartWriteStepAttribFloat32
H5PartWriteStepAttribFloat64
etc.

I would like to propose that we remove the many-type function calls from 
H5hut.

One potential issue is that users may have H5hut files that don't
conform to some predetermined convention (e.g. the attribute "foo" is
always a float32), and they need to query the attribute to determine
its type:

H5PartGetStepAttribInfo(...)

then have a switch to read the attribute:

switch(type):
case H5PART_FLOAT32 ... H5PartReadStepAttribFloat32
etc.

which is more complicated than if there were a many-type read function:

H5PartReadStepAttrib( ... type ... )

But we've clearly tried to establish a convention to get away from
many-type functions, so I think we should continue in that direction.

Another option is to leave the query and many-type functions out of
the high-level H5 API, but leave it in the h5core API for more
advanced users.

What do others think?

Thanks
Mark