Robotics Service Bus

h1. Meeting 2010-11-10

* Sequencing:

** Spread-specific: -> sequencing only in spread port, remove sequencing stuff from Notification.proto, add second message type only with sequencing information wrapped around serialized Notification

** Parallelization of sequencing to reduce send and receive times

* Quality-of-Service:

** Ordered notifications required

** Ports are responsible, because spread e.g. already can order notifications -> why order by hand here?

** Extract manual logic for ordering to be reusable

** Where is the desired service type specified?

*** Probably statically in a global system configuration... later

*** Simple solution right now: QoS-Objekt set at publisher with port observing the publisher, or pub sets the QoS in the port with error if not supported

**** Later maybe also QoS specification at subscriber

** Current QoS-Types:

*** Unordered

*** Ordered per Subscriber-Publisher pair

* Distributed Nameservice:

** Event-based telling what's going on on each logical message bus

** May be replaced with a static system model, but not required

* URL scheme:

** Hashing of URLs

** Service required to translate back between hashes to real URLs (nameservice)

** Hierarchy

* Performance testing:

** Throughput with spread

** Why jitter, how to avoid it? Is this only because of the hacked spread?

** Jitter would be bad for sequencing

* Tool support required

** Web-Server

** command-Line tools for introspection

** Implemented as MVC-Pattern with different views

* Type to data mapping in C++

** Use RTTI?

** Benchmark Performance

** Current steps:

*** Use RTTI to simplify generic interface

** later:

*** Maybe code generation from model with specific interfaces

*** Hierarchies of types currently ignored