deprecating support for HDF5 files in load/save

[John W. Eaton]

I'd like for us to consider deprecating support for HDF5 files in the
load and save functions, at least as it is currently implemented.
Some reasons for this are

  * Saving in the HDF5 format does not currently work for diagonal or
    permutation matrices.

  * As I recall, David has said that he doesn't think the structure of
    the HDF5 files that we generate is as good as it could be, but
    there is little hope of fixing this and keeping backward
    compatibility.

  * Some users seem to think that the load function should be able to
    intelligently handle any HDF5 file, but most likely it will only 
    only work properly for HDF5 files that were generated with
    Octave's save command using the "-hdf5" option.

Instead of having specialized and limited support for HDF5 files
hardwired into the save and load commands, I'd prefer to have a
lower-level wrapper for important functions from the HDF5 library
interface.  Using those, I would expect that you could read or write
most HDF5 files with Octave, and we could also use them to create
Matlab-compatible hdf5info, hdf5read, and hdf5write functions.  It
might also be useful to organize the low-level functions in a
compatible class hierarchy.

But even if we don't have these functions now, I think we should
deprecate the HDF5 capability of the load and save functions because
they are broken and it seems unlikely that they will be fixed any time
soon.  I also think it requires too much effort to have to deal with
text, binary, and hdf5 formats in load and save.

Note that I'm not volunteering to write these functions.  This work
should be done by someone with some knowledge and interest in the HDF5
format (I currently have neither).  However, I could provide some help
with the design and perhaps parts of the implementation.

Comments?

jwe