Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
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: