On 2004.07.16 11:44 John Caron wrote:
Is the requirement that we support one type of compression, both
of compression that currently exist in the library (gzip and szip),
IMNSHO, we should disallow user-defined file filters, since they make
files non-portable (if i understand them correctly). If they need
that, they should use HDF5. The compression filters should be limited
to ones we can read in Java.
that we support all compression filters that may be introduced in the
Or is the requirement that we support file filters, including all the
ones listed above?
If yes to the last question, is it also a requirement that we allow
the user to register callbacks, etc., and so add his own filters to
netCDF-4, just as HDF5 does?
This is a very fundamental problem for the Java implementation. It's
to be difficult to rewrite all the filters people want to use in Java.
Users already use their own filters and file drivers, and it would be
unfortunate to tell them that they can't use those in the C version of
Also, anything that netCDF4 prohibits, users will do through the HDF5
APIs. This will make the files more difficult to interpret.
My general view is that netCDF4 must not be driven by the limitations of
the Java implementation. It should let people use as much of HDF5 as
they can through the netCDF4 APIs.