Context: Commands are too complex for both users and framework/transport implementers. However, current day-to-day use confirms the usability of an asynchronous and thread-safe messaging mechanism. It was proposed to reduce the command API to a message API and unify the synchronous / asynchronous relation between methods and messages with synchronous / asynchronous events. This will lead to simpler implementations, simpler usage scenarios and reduced concepts in the RTT.
The registration and connection API of these primitives also falls under this WP.
Link: http://www.orocos.org/wiki/rtt/rtt-2.0/executionflow
Estimated work : 55 days for a demonstrable prototype.
Tasks:
3.1 Provide a real-time memory allocator for messages
In contrast to commands, each message invocation leads to a new message sent to the receiver. This requires heap management from a real-time memory allocator, such as the highly recommended TLSF (Two-Level Segregate Fit) allocator, which must be integrated in the RTT code base. If the RTOS provides, the native RTOS memory allocator is used, such as in Xenomai.
| Deliverable | Title | Form |
| 3.1.1 | Real-time allocation integrated in RTT-2.0 | Patch set |
3.2 Message implementation
Unit test and implement the new Message API for use in C++ and scripts. This implies a MessageProcessor (replaces CommandProcessor), a 'messages()' interface and using it in scripting.
| Deliverable | Title | Form |
| 3.2.1 | Message implementation for C++ | Patch set |
| 3.2.2 | Message implementation for Scripting | Patch set |
3.3 Demote the Command implementation
Commands (as they are now) become second rang because they don't appear in the interface anymore, being replaced by messages. Users may still build Command objects at the client side both in C++ as in scripting. The need for and the plausibility of identical functionality with today's Command objects is yet to be investigated.
| Deliverable | Title | Form |
| 3.3.1 | Client side C++ Command construction | Patch set |
| 3.3.2 | Client side scripting command creation | Patch set |
3.4 Unify the C++ Event API with Method/Message semantics
Events today duplicate much of method/command functionality, because they also allow synchronous / asynchronous communication between components. It is the intention to replace much of the implementation with interfaces to methods and messages and let events cause Methods to be called or Messages to be sent. This change will remove the EventProcessor, which will be replaced by the MessageProcessor. This will greatly simplify the event API and semantics for new users. Another change is that allowing calling Events on the component's interface can only be done by means of registering it as a method or message.
| Deliverable | Title | Form |
| 3.4.1 | Connection of only Method/Message objects to events | Patch set |
| 3.4.2 | Adding events as methods or messages to the TaskContext interface. | Patch set |
3.5 Allow event delivery policies
Adding a callback to an event puts a burden on the event emitter. The owner of the event must be allowed to impose a policy on the event such that this burden can be bounded. One such policy can be that all callbacks must be executed outside the thread of the owning component. This task is to extend the RTT such that it contains such a policy.
| Deliverable | Title | Form |
| 3.5.1 | Allow to set the event delivery policy for each component | Patch set |
3.6 Allow to specify requires interfaces
Today one can connect data ports automatically because both providing and requiring data is presented in the interface. This is not so for methods, messages or events. This task makes it possible to describe which of these primitives a component requires from a peer such that they can be automatically connected during application deployment. The required primitives are grouped in interfaces, such that they can be connected as a group from provider to requirer.
| Deliverable | Title | Form |
| 3.6.1 | Mechanism to list the requires interface of a component | Patch set |
| 3.6.2 | Feature to connect interfaces in deployment component. | Patch set |
3.7 Improve and create Method/Message CORBA API
With the experience of the RTT 1.0 IDL API, the existing API is improved to reduce the danger of memory leaks and allow easier access to Orocos components when using only the CORBA IDL. The idea is to remove the Method and Command interfaces and change the create methods in CommandInterface and MethodInterface to execute functions.
| Deliverable | Title | Form |
| 3.7.1 | Simplify CORBA API | Patch set |
3.8 Port new Event mechanism to CORBA
Since the new Event mechanism will seamlessly integrate with the Method/Message API, a CORBA port, which allows remote components to subscribe to component events must be straightforward to make.
| Deliverable | Title | Form |
| 3.8.1 | CORBA idl and implementation for using events. | Patch set |
3.9 Update documentation, unit tests and Examples
In compliance with modern programming art, the unit tests should always test and pass the implementation. Documentation and Examples are provided for the users and complement the unit tests.
| Deliverable | Title | Form |
| 3.9.1 | Unit tests updated | Patch set |
| 3.9.2 | rtt-examples, rtt-exercises updated | Patch set |
| 3.9.3 | Orocos component builders manual updated | Patch set |
3.10 Organize and Port OCL deployment, taskbrowsing
The new RTT 2.0 execution API will require a coordinated action from all OCL component maintainers to port and test the components to OCL 2.0 in order to use the new primitives. This work package is only concerned with the upgrading of the Deployment, Reporting and TaskBrowser components.
| Deliverable | Title | Form |
| 3.10.1 | Deployment, Reporting and TaskBrowser updated | Patch set |