Re: restructuring load-save

[John W. Eaton]

On 20-Nov-2003, David Bateman <address@hidden> wrote:

| I've not really looked at the matlab or hdf functions yet, but hope they 
| might be dealt with in a similar manner.

For the MAT file format, I think we are stuck with just the types that
are allowed by the format.  We can't extend it to handle new types on
our own.  Their is the provision for "object" types, but I think that
is just the same as a structure plus a class name, so the data stored
for a class object must look like a structure which is composed of
field names and existing data types.  Of course this could all change
with the next release of Matlab...

For the HDF format, I think we can do whatever we want, but I'm
beginning to wonder whether we really want HDF as a part of
load/save.  It might be better to have a more general interface for
HDF.

Then we would only (ever) support the following formats for load/save:

  octave-binary
           The default format.  Every data type should fully support
           this format.  We can update the format of this file
           slightly to more cleanly support user-defined types.  We
           will still need to support loading the old format, or
           provide a conversion utility.

  octave-ascii
           Freeze this one as it is now so we don't have to support
           two different native file types for Octave.  Eventually
           this could be deprecated and removed.

  mat5     For compatibility.  Some might even want this as the
           default format, but I don't think we should go that far.

  ascii    Matlab simple ascii format for real matrices.  For
           compatibility, change the interface of save so the -ascii
           option means this format, not the old octave-ascii format.

  mat4     Should be relatively easy as it is not changing, so we may
           as well keep it for compatibility.  It does not need to be
           able to save and load all types (it can't do it now and it
           won't do it in the future).

  hdf5     Deprecate and remove in favor of a library of HDF5
           functions for Octave.

Alternatively, we change the octave-binary format to use HDF5
internally.  We could still provide a library of HDF5 functions for
Octave, perhaps even allowing the load/save functionality for the
octave-binary file format to be written in the scripting langauge
instead of C++.  The downside of this is that Octave would then depend
on HDF5, so to have a fully functional copy of Octave, you would need
to have HDF5 working on your system first, and I'm not sure we want to
have the added dependency.

Finally, it would be nice to provide a separate library for reading
and writing the mat5 and octave-binary file types that could be used
outside of Octave.

jwe