Meetings2011-03-17 » History » Version 14
Version 13 (J. Wienke, 03/17/2011 03:41 PM) → Version 14/15 (J. Wienke, 03/17/2011 03:50 PM)
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: 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
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: 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