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.
Steve, > One question, though. Where should the decision to use FileFlatFields > be made? In the Form's? In the Repository? By the user? The > java.lang.Runtime.getMemoryAdvice() method, which indicates the level of > memory usage, might be applicable. In the design you and I and others worked out last October, Forms construct Data objects so Forms decide whether to use FileFlatFields. Forms also pass CacheStrategy objects to FileFlatField constructors, which also lets Forms decide how to manage data migration between memory and disk. We could add methods to Form and / or Repository to pass this decision up to the application. Letting applications control these decisions is nice, but would put a burden on all Forms to support FileFlatFields. Of course, as more Forms are written, applications may have some control over these decision just by their choice of Forms. I think for the time being, we should leave it as is. Note that you are free to write Forms and CacheStrategys that use the java.lang.Runtime.getMemoryAdvice() method to decide how to manage data migration. Bill ---------------------------------------------------------- Bill Hibbard, SSEC, 1225 W. Dayton St., Madison, WI 53706 whibbard@xxxxxxxxxxxxx 608-263-4427 fax: 608-263-6738 http://www.ssec.wisc.edu/~billh/vis.html
visad archives: