As begun in "Boot loader", and continued in "Toolkit", data handling and binding is a central issue in many kinds of systems -- not least of all in Fv3.
First, Fv3 is a data parallel environment in service of the data parallel architecture of modern computer graphics hardware and its GL interface. In order to efficiently feed diverse and arbitrary data needs, Fv3 implements a file cache for web content. Over this file cache, Fv3 employs both memory buffering and file mapping strategies for loading data.
For example, the Fv3ds model loader employs file mapping to minimize the load time of large models transferred in this highly efficient file format. For this reason, the 3ds file format will be one of the most efficient ways to store and display large models in Fv3.
Data binding refers to the association of data with named or active elements of a system. Fv3 will use data binding from XML onto Java programming classes -- similarly to what WTKX did with conventional Java 2D graphics. This binding will configure a world, region or model into the screen view almost like a web HTML page does.
Unlike HTML, the Fv3 JBX files will be endlessly extensible for producing systems and applications.
Underlying the Fv3 data binding architecture are two processes. One binding XML onto Java Beans in JBXML, and the other binds Java Beans into template processing for source code generation in Hapax3. Static Design Time, and Dynamic Run Time source code generation and compilation are both open avenues for work and exploration in the future of Fv3.
Among other open topics in this work is the planned review of Jela, a part of JBX that adds Java Programming Language functions to JBXML. Currently, Jela functions add a layer of java method invocation to the execution path. While fast, this will inhibit the performance of Fv3. In future, Jela functions will be bound into a target component subclass for the runtime performance of normal plain old java code.