As stated earlier, the most common approach for VR
application development is one where the application defines the
main() function. That
main() function in turn calls library
functions when needed. (This is the model followed by software
packages such as the CAVElibs™ and the
Diverse Toolkit.) The library in this model only executes code
when directed to do so by the application. As a result, the
application developer is responsible for coordinating the
execution of the different VR system components. This can lead to
complex applications.
As a virtual platform, VR Juggler does not use the model described above because VR Juggler needs to maintain control of the system components. This control is necessary to make changes to the virtual platform at run time. As the controller of the execution, the kernel always knows the current state of the applications, and therefore, it can manage the run-time reconfigurations of the virtual environment safely. With run-time reconfiguration, it is possible to switch applications, start new devices, reconfigure running devices, and send reconfiguration information to the application object.
Application objects lead to a robust architecture as a result of low coupling and well-defined inter-object dependencies. The application interface defines the only communication path between the application and the virtual platform, and this allows restriction of inter-object dependencies. This decreased coupling allows changes in the system to be localized, and thus, changes to one object will not affect another unless the interface itself is changed. The result is code that is more robust and more extensible.
Because the application is simply an object, it is possibly to load and unload applications dynamically. When the virtual platform initializes, it waits for an application to be passed to it. When the application is given to the VR Juggler kernel at run time, the kernel performs a few initialization steps and then executes the application.
Since applications use a distinct interface to communicate with the virtual platform, changes to the implementation of the virtual platform do not affect the application. Changes could include bug fixes, performance tuning, or new device support.
By treating applications as objects, we can mix
programming languages in the VR Juggler kernel. For example, an
application object could be written in Python, C#, or even
VB.NET, but the VR Juggler kernel (written in standard C++)
will still see it as an instance of the abstract interface
vrj::App. The use of application objects has allowed
such extensions to VR Juggler to be written without requiring
any changes to VR Juggler.