Meetings2014-03-17 » History » Version 12
Version 11 (S. Wrede, 03/17/2014 03:47 PM) → Version 12/13 (S. Wrede, 03/17/2014 04:03 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?
** 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?
h3. h2. Named Participants
* Name participants within a "composite / group / ..."
* Add interface type information to 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?
** 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?
h3. h2. Named Participants
* Name participants within a "composite / group / ..."
* Add interface type information to participants?