Morning

Peter started to present the 2.x functionality, state and (from its point of view), shortcomings. The following are the points that have been risen during the discussion.

• TimeService: what is it for, and is not there other solutions ?
• right now, SlaveActivity is different from Slave execution engine. Why ?

Properties and attributes

• RTT::Property[persistent] / RTT::Attribute[non persistent]
• RTT::Property is NOT thread safe
• know if a property has been written

Ports

• could we have not OldData for buffer ports => how difficult ?
• discussion on overruns, and default drop policy for buffers. In general, we need to discuss an interface to monitor transports
• data flow now has N data holder elements, where N is the number of total connections. 1.x needed at most one data holder element per output port.

Methods / Operations / Services

• operation execution policy: OwnThread vs.ClientThread. Agreed that OwnThread should be the default policy as it is safer from a thread-safety point of view.
• better naming for ServiceRequester / ServiceProvider -- Method / Operation
  • rename ServiceRequester to Service to map Operation
  • what about the caller side ?
    • OperationHandle
    • __OperationCaller__ for now, preferred as it says what it does
    • PeerOperation
    • RemoteOperation
    • OperationProxy (-- for Peter and Markus)
    • OperationStub (-- for Peter and Markus)
    • OperationInterface (no: Interface is used a lot in the code for base classes)

Misc

• chicken and egg problem with the deployer, especially with basic services like real-time logging

Plugins

• possibility to do autoloading based on a PATH environment variable or to do loading per-plugin
• there is a cost to load a typekit that is not needed as the shared library has to be mapped in memory and typekits are quite big

Code size

• instanciating RTT::Operation for void()(void)
  • 60kB for dispatching code
  • 60kB for distributed C++ dispatching code
  • Yuk

Events

• 2.0 does not have events right now
• can (and will) be implemented on top of the ports
• one limitation: only one argument. Not a big issue if we have an automated wrapping like oroGen
• we're now getting into the details of event handling ;-)

end