NOTE: The netcdf-hdf mailing list is no longer active. The list archives are made available for historical reasons.
On 2004.07.16 11:44 John Caron wrote:
Is the requirement that we support one type of compression, both types of compression that currently exist in the library (gzip and szip), orIMNSHO, 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 future? 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? Ed
This is a very fundamental problem for the Java implementation. It's going 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 ofnetCDF4. 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. --REMcG
netcdf-hdf archives: