A number of different topologies of ADI objects with respect to the application are possible. Figure 1 shows the three varieties.
Figure 1: Example ADI object topologies
In the first of three schemes the ADI class instance has no connection to the file system. In this case the the object resides purely in memory, ie. it is a virtual dataset. Asterix currently supports dynamic numeric arrays, but this facility allows complete dynamic datasets to be constructed. It also allows the possibility of testing class behaviour before the the file interface is written.
The second example shows the most common case where an ADI object is
mediating exchanges between the application and the underlying file
system. When a file interface is required ADI creates an instance of
a class File which stores the file format specific information needed
to control the file. The BinDS object communicates both with the File
and with the file format directly using class methods. The trailing
%HDS on the File box will be explained soon.
The third example shows a more complex setup where an intermediate ADI instance of XYimage has been interposed between the application and the EventDS object closest to the File The ADI system allows such chains to be constructed and controls the communication between such objects. The application in this example could handle inputs of event datasets when it was expecting an image as long the criteria for setting up the network of objects had been met (which would boil down to spatial fields existing in the event list).