| | 1 | [wiki:WikiStart Orbit] > [wiki:OTG OTG] > [wiki:OTG/FuncSpec Function Specifications] > OML Integration |
| | 2 | |
| | 3 | = Function Specification: Integration with OML = |
| | 4 | |
| | 5 | == Design == |
| | 6 | |
| | 7 | To isolate/encapsulate all OML-related functions, a class [source:otg/trunk/src/cpp/orbitapp.h#latest OrbitApp] is designed. |
| | 8 | All other design components/objects shall not care about measurements reporting mechanism and the interaction with OML. |
| | 9 | This class derived three child classes for respective appliactions. |
| | 10 | |
| | 11 | http://www.winlab.rutgers.edu/~zhibinwu/image/classOrbitApp.png [[BR]] |
| | 12 | Figure 1. Class Hierarchy for OrbitApp |
| | 13 | |
| | 14 | == Implementation == |
| | 15 | |
| | 16 | All functons to call OML are put as pure virtual functions in this base class. OTG/OTR/OTFApp can select to implement a subset of those functions. This design has some advantages: |
| | 17 | * to make OTF to reuse the Stream/Port/Gate structure of as a combination of OTG/OTR |
| | 18 | * to share some common functions for all OTG/OTR/OTFApp, such as close() |
| | 19 | |
| | 20 | The class has a boolean varialbe to indicate if OML will be used or not. If it is false, all measurement reports will be redireted to a local log file. This is a special debugging mode. And it could also be served as a means to use OTG outside of ORBIT testbed. |
| | 21 | |
| | 22 | OML calls are actually implemented externally by OML-client libraries. So, special header files are fetched dynamically in compilation. Those header files have to be included here. For example: |
| | 23 | * #include "oml_orbit_winlab_otg.h" in otg_application.h |
| | 24 | * #include "oml_orbit_winlab_otr.h" in otr_application.h |
| | 25 | |
