Dave Allured

Ward, agreed about not breaking existing code. However there should be exceptions for codes that have a strict expectation for define mode, and actually check for it and break when...

Ed, yes, those are all good points. Yet in my opinion, they are all outweighed by the benefits of a simpler code base and API model. I recall that freedom...

Ed, let's keep this proposal going. Sorry for my delayed response. Repeating with emphasis, I believe that the benefits greatly outweigh the downside. Break code compatibility: Technically yes, but highly...

Other formats: Yes, avoid enddef/redef as much as possible. I think the **only** reason these were part of the original netCDF API was for performance improvement when managing the relatively...

CLASSIC_MODEL flag: Opinion: No, unnecessary complexity. I think most developers know by now how to design for the desired compatibility level. The community has been fumbling and solving similar issues...

It appears there is a compatibility mode in HDF5 1.10 for writing downward compatible netcdf-4 files. Would someone please confirm my interpretation of the release documentation? Please read under "Obtaining,...

@epourmal, > Second, it is my understanding that Java reader can deal only with HDF5 file format that was available in HDF5 1.8.0 release. It was not updated to deal...

> Unfortunately, sticking with 1.8 file format features ... Yes. Please see Unidata/netcdf-c#951.

@dopplershift wrote: > There are clients in many languages on a diverse set of platforms that need to be considered. IMO, anyone proposing additions should be considering the impacts of...

@edwardhartnett write: > @Dave-Allured I agree it would be a great thing if we can achieve Unidata/netcdf-c#951. Let me know if you want some help putting a PR together. Given...