Rapicorn - Experimental UI Toolkit - Source Code  13.07.0
Aida - Abstract Interface Definition Architecture

Aida is an architecture, centered around abstract interface definitions, used for programming of remote objects.

The "aidacc" compiler is used to compile Aida IDL files into executable code.

Motivating considerations for the creation of Aida.

  1. Expressive IDL - The IDL syntax is designed to at least cover the use cases of aRts, Beast and Rapicorn:
    • The IDL supports primitive types: integer, double precision floating point, string and any.
    • The IDL supports structured types: enums, records, sequences and interfaces.
    • Interfaces have support for methods, properties, signals and IO streams.
      UNIMPLEMENTED: Streams are still TODO
    • Auxiliary data is supported for enum values and properties.
      UNIMPLEMENTED: Streams are still TODO
    • Auxiliary data is specified in form of key=utf8value string pairs, so it can be used for arbitrary extensions like tooltips, float boundaries or icon references.
    • Two way calls from the client to the server are supported by blocking for arrival of the return value of a method.
    • One way calls from the client to the server are always carried out in non-blocking fashion.
    • For notification purposes, the server can emit signals, which are dispatched via callbacks on the client side.
  2. Extensible Code Generation
    • The IDL parser is implemented in Python, as are the code generators.
    • Code generators are loaded as external Python modules.
    • Choosing Python has acceptable real-world performance and has shown to be very useful to prototype new IDL or code generator features.
    • Aidacc allows custom code generator implementations, implemented as external python scripts.
  3. API & ABI Separation
    • The generated C++ code goes through some lengths to ensure best client side ABI flexibility.
    • ABI flexibility is achieved by providing access to the various API bits through non-virtual methods, which can be freely added to and removed from C++ classes without affecting ABI compatibility of any other API parts.
    • Methods can be added to interfaces without breaking ABI.
    • Properties can be added to interfaces without breaking ABI.
    • Signals can be added to interfaces without breaking ABI.
    • IO Streams are planned to be implemented in an ABI preserving fashion as well.
      UNIMPLEMENTED: ABI-stable IO Stream implementations have yet to be researched.
    • This allows isolation of the client API of a library, which is subject to various ABI and source compatibility constraints.
    • Full ABI compatibility is maintained on the client side, as long as API functionality is only added (classes, methods).
    • For controlled deprecation and removal of features, ABI impact can be limited and controlled.
  4. Standalone Executables
    • The generated C++ code for the client side as well as the server side is structured to be easily included into existing programs or libraries, without needing any additional administrative process (like a network object broker).
    • The Aida IPC layer can be used within executables and libraries directly.
  5. IPC Separation
    • The generated C++ code separates client and server functionality through an Aida::ClientConnection abstraction.
    • This allows remote invocation of the server functions through the client API (currently across threads).
    • Full developer control is provided on the server and client side about threading, remote connection use and main loop integration.
  6. Reference Counting
    • Client side interface instances are always accessed through smart-pointers which automate reference counting.
    • Remote instance lifetime is tracked through ref-counting per connections.
      UNIMPLEMENTED: TODO: port Beast ref counting
    • All client side API uses are meant to be either automatically reference counted (C++) or garbage collected (Python). The corresponding logic is implemented in the respective code generators.
  7. Performance - The IDL and generated C++ code is designed, profiled and optimized as follows:
    • Optimized IPC calls for low-latency dispatching require the Rapicorn::EventLoop implementation.
    • Generate acceptable throughput in high-performance computing scenarios (pseudo realtime).
      UNIMPLEMENTED: The details of the Aida data port implementation still need to be finalized
    • Allow zero-copy high-bandwidth data throughput for images and audio.
      UNIMPLEMENTED: Needs shared data ports
  8. Miscellaneous
    • For Beast and Rapicorn, Aida is meant as a replacement for the chaotic growth of code generators, such as glib-mkenums.pl, bse/mkcproc.pl, function call marshallers, etc.

Design Considerations

ImplicitBase

In the server side C++ implementations, all generated interfaces are (directly or indirectly) derived from Rapicorn::Aida::ImplicitBase. ImplicitBase provides means to introspect properties on an instance and to query the "final" type of an instance.

Instance Type

For dynamic language bindings such as Python, every accessible instance needs to have a "final" type that has been specified in an IDL file. This type is what is returned from the Rapicorn::Aida::ImplicitBase.__aida_type_name__() method that all instances implement. To ensure this property, implementation classes that implement multiple IDL interfaces should ultimately derive a single IDL interface which in turn derives (directly or indirectly) from all of the required IDL interfaces.

 All Classes Namespaces Files Functions Variables Typedefs Enumerations Enumerator Defines