A. First day

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