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