Getting Started

Documentation

Glish

Learn More

Programming

Contact Us

Version 1.9 Build 1556

News	FAQ
Search	Home

Interoperability options

As discussed in the previous section, a significant consideration in this matter is the exact degree of interoperability that is envisaged between the two systems and the manner by which this is achieved. Specific options that might be made available to an AIPS++ user or programmer include the following capabilities:

• Enhancement of and access to the AIPS CLI: This includes the ability to launch standard AIPS tasks acting on AIPS data from the AIPS++ CLI, and the ready implementation of an AIPS graphical user interface (GUI) in Glish/Tk.

• Invoke AIPS components from Glish: This would involve the provision of specialized AIPS components to serve selected AIPS data or algorithms to the AIPS++ command line environment. These would most readily be implemented as Glish distributed objects (DO). This option is most closely related to improved user programmability. The AIPS and AIPS++ data could also be passed to other command line environments including IDL or Mathematica.

• Provide a C++ interface to the AIPS libraries: In this approach, selected AIPS libraries could be provided with a C++ calling interface, as has been pursued with other external libraries. This would allow an AIPS++ programmer to re-use some AIPS algorithms with a direct binding.

• Recognition of the AIPS data format: AIPS++ applications could be made aware of the AIPS data format and be able to act on AIPS data files directly.

• Documentation: The ease with which users will be able to navigate the AIPS/AIPS++ transition will depend on the quality of documentation describing the available interoperability options. The transition points between the two systems are likely to change dramatically on short time scales during this period.

Several of these options have disadvantages and are not emphasized in the design as a result. These include the possibility of recognizing AIPS data from within AIPS++ applications and the provision of a direct C++ binding to the standard AIPS libraries. Both significantly influence the design of the two packages considered as separate stand-alone entities, would be expensive to implement and are impractical due to the mismatch in data and function representation. In particular, a direct C++ binding to the AIPS libraries is difficult due to the lack of a clear external interface to many of the routines and the limited encapsulation of global data. It would also require close synchronization with continuing evolution in the AIPS libraries and would therefore significantly influence the development of each system considered as a stand-alone entity, thus violating the design objectives given above. A direct binding may be possible in some cases however and is not excluded.

Likewise, the recognition of AIPS data from within AIPS++ applications is ruled out because of the significant overhead this would place on the development of native applications. This is fundamentally due to the mismatch in data representation and the implied requirement of replicating significant parts of the AIPS infrastructure within the AIPS++ libraries.

A design that provides access to AIPS data and algorithms, while avoiding the disadvantages listed here, is given in the next section.