NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
Don, > > Great suggestion, Curtis. But my recent strategy has been to > > keep the core VisAD functionality stable, so I think it would > > be best to do this in the application. Hope that's not a > > problem. > > Since it wouldn't change the existing behavior and would be > a good enhancement that is controlled by the user, I'm not > sure why this would destabilize the VisAD core? > > Maybe there's more to it than Curtis's description? It would be a pretty complex change in an area of code that no one but me has ever worked in. My general attitude is to resist such changes if the need can be addressed in applications, especially when they are for changes that haven't been previously requested by other users. I ma concerned about making complex code more complex, and introducing new bugs (especially some that may not manifest until years later). I am open to changes that are truly needed by applications, such as the extensive changes that Unidata (specifically Jeff McWhirter) made to reduce garbage collection. Another good example is the change for multi-resolution displays that VisBio needed. Curtis and I have communicated privately about this, and I am open to his change if he thinks he really needs it. Bill
visad
archives: