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