Matlabs data format as Octaves native format? (was: Re: classdef is pretty good now ...)

[Olaf Till]

On Fri, Aug 22, 2014 at 10:34:31AM -0400, John W. Eaton wrote:
>
> ...
> 
> In any case, I think now might be a good time to decide whether we should
> continue to support all of the various forms of data files that load/save
> handles or deprecate and eventually drop them in favor of only supporting
> the MAT style that uses HDF5, possibly with extensions.
> 
> The formats we currently support includes Octave text, Octave binary, Octave
> HDF5, MATvN.  Dealing with all of them represents a pretty large maintenance
> burden for us. I don't count the ascii format here because that is just for
> saving numeric data without any header info, and the old MATv4 format won't
> change, so very little maintenance is required. But keeping all of them
> means that any time we want to add something like support for classdef
> objects, we have to update at least four different formats.  That's a lot of
> extra work.
> 
> Also, I don't think we really support the latest HDF5-based file format used
> by Matlab.  So maybe the best thing to do would be to add support for the
> latest HDF5-based Matlab format and only add classdef support for that
> format.  We could keep the others, but not extend them to classdef or any
> other new data types that we add and eventually phase them out except for
> reading old data files.
> 
> jwe

(Was pointed to this thread by
https://savannah.gnu.org/bugs/index.php?45831 and
https://savannah.gnu.org/bugs/index.php?45833 .)

I'm not familiar with HDF5, but surely, although it's a free framework
format, one would need additional information to support the Matlab
format based on HDF5?

It might be technically easy (I don't know) to get this information
from reading data saved in this format by Matlab, but ... I am not a
lawyer but I remember some speech on video by RMS ... If I understood
it right, there could be the possibility that software companies try
to make it illegal to implement a file format using information from
files output by their software, so possibly there could be the risk to
have to stop using this format some time in the future (?).

If that should indeed be so, it might be a risk to use a Matlab data
format as Octaves native data format, since its use might be forced to
be stopped some time. (Although it could still be reasonable to try to
support the Matlab format as an alternative, as long as there are no
such legal restrictions.)

Again, that's only a thought, I don't know enough about it. But maybe
one should consider contacting the FSF before making a decision about
the data formats supported in the future. (And I got the feeling that
a decision is needed now ...)

Olaf

-- 
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

signature.asc
Description: Digital signature