Robotics Service Bus

h1. Meetings2011-03-17

Topics:

* Michael ;)

* Jan ;)

* URIs...

h2. Message Fragmentation

* Only c++ right now

** missing:

*** Python

*** Java

*** Common LISP

* blocks of size 100k

* recombination missing

* Notification contains total number of blocks and number of current block

* spread UNSAFE_MESS does not guarantee sequencing of messages -> recombination with ordering and waiting required in input port

* What to do with missing messages (e.g. directly when starting a subscription there could be only the last half of a message received)

** simple strategy: Timeout for finalization of a message to dispatch

* Configuration of block size as a simple hack in current class...

h2. Jan's Question Collection

h3. Names

* Event Payload: User data in an event

* Wire Type: data type of serialized representation, e.g. bytes, has a language mapping

* Wire Schema: schema of serialized data, descriptor, IDL?

** dependent of wire type

* Converter:

** Currently only for event payload

** serializes payload to wire type according to wire schema

** and vice versa

h3. Why Ports Bidirectional?

* Sebastian: one implementation is enough based on common ground

* Jan: Current scheme restricts usage cardinalities

* Still could be useful in future

h3. Should (Spread) Ports Know Who Is Receiving Data

* Spread: group members

* no sending would be required if there is no receiver

* Sebastian: not important as usecase

* Naming: requires a more global strategy to provide kind of membership information

h3. How Much Functionality and Dynamics in Subscriptions?

* updates of filters etc.

* which changes of a subscription can or have to trigger naming events?

* First iteration: subscriptions are immutable

h3. Filter Whitelisting

* Ports should mark which filter was already filtered in the port -> avoid filtering twice

* two possibilities:

*# filter knows which event to not filter by id

*# external component knows which filters not to use

* relevant: multiple in-ports for subscriber

h3. Grundannahmen

Kern-Domänenobjekte:

* *1* Bus: (m:n Kommunikation) über alle Transportmöglichkeiten in RSB, nur logisches Konstrukt, realisiert über Kombination mehrer Ports

* Channel: Topic auf Bus mit m:n Kommunikation, Ist kein Pattern da er den Bus über Aggregation von Ports realisiert. Ports müssen vom Nutzer angegeben werden wenn noch kein Modell vorhanden ist. Hat einen global einschränkenden Scope-Filter. Besitzt n Listener.

* Topic: Inhaltliche Einschränkung des Broadcast

* Listener: Teilnehmer an einem Channel mit Filter Chain, entweder synchrones oder asynchrones empfangen (aktuell: Subscription), eindeutig identifizierbar im System

* Informer: Schreibende Komponente auf Channel, eindeutig identifizierbar im System.

Pattern-Domänenobjekte:

Publisher: 1:n Kommunikation, könnte evtl. Garantie anbieten, dass er zuerst existiert

Subscriber: 1:n Empfänger