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.
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: