Meetings2014-03-17 » History » Version 10
S. Wrede, 03/17/2014 03:42 PM
| 1 | 1 | S. Wrede | h1. Meetings2014-03-17 |
|---|---|---|---|
| 2 | 1 | S. Wrede | |
| 3 | 2 | S. Wrede | h2. RSB Component/Service/Group/Composite Semantics |
| 4 | 1 | S. Wrede | |
| 5 | 1 | S. Wrede | * Currently, we lack the possibility to group participants and treat these as a kind of "component". |
| 6 | 1 | S. Wrede | * We (Jan, Arne, Sebastian) consider such a group of participants useful. |
| 7 | 1 | S. Wrede | * Features that relate to this notion of "components/groups/composites" could be: |
| 8 | 8 | S. Wrede | ** Has own id and is participant |
| 9 | 7 | S. Wrede | ** Assign (composite) transport configurations with default configurations that can be optionally overwritten |
| 10 | 10 | S. Wrede | ** Assign (optional) / share common scope prefix? |
| 11 | 9 | S. Wrede | ** Describe / prescribe (?) "component" interfaces (cf. RSB DSL) for the involved participants |
| 12 | 1 | S. Wrede | * Should "components/groups/..." be restricted to a single process? |
| 13 | 10 | S. Wrede | * Couldn't the Participant implement the Composite semantics and the existing RSB pattern objects (Informer, Listener, ...) be the leafs? |
| 14 | 6 | S. Wrede | |
| 15 | 6 | S. Wrede | h2. Named Participants |