Meetings2012-02-16 » History » Version 13
J. Moringen, 02/16/2012 05:17 PM
headline promotion
| 1 | 1 | J. Moringen | h1. Meetings 2012-02-16 |
|---|---|---|---|
| 2 | 1 | J. Moringen | |
| 3 | 13 | J. Moringen | h2. Nomenclature |
| 4 | 2 | J. Moringen | |
| 5 | 7 | J. Moringen | * Configuration (Framework level) |
| 6 | 7 | J. Moringen | ** Converter [implemented] |
| 7 | 7 | J. Moringen | ** Transports (+ quality of service) [implemented] |
| 8 | 7 | J. Moringen | ** Error handling [implemented] |
| 9 | 8 | J. Moringen | ** (Renaming of) scope names [not implemented] |
| 10 | 7 | J. Moringen | *** Are these renaming rules, which are applied at participant creation time? |
| 11 | 7 | J. Moringen | *** Do they affect scopes or participants? |
| 12 | 9 | J. Moringen | * Parameter Service (Domain level) |
| 13 | 9 | J. Moringen | ** Component parameters |
| 14 | 1 | J. Moringen | *** Component-specific configuration has to be possible |
| 15 | 9 | J. Moringen | *** Changable at runtime? |
| 16 | 2 | J. Moringen | |
| 17 | 13 | J. Moringen | h2. Requirements |
| 18 | 2 | J. Moringen | |
| 19 | 4 | J. Moringen | * Remapping of scope names |
| 20 | 4 | J. Moringen | ** Remapping on the program-level is sufficient (i.e. participant level is not needed) |
| 21 | 1 | J. Moringen | ** Recursive renaming has be possible |
| 22 | 10 | J. Moringen | ** The remapping mechanism is applied when participants are instantiated |
| 23 | 12 | J. Moringen | ** Look at ROS's approach: syntax should be similar, when possible |
| 24 | 1 | J. Moringen | |
| 25 | 11 | J. Moringen | * Reconfiguration of participants is not required |
| 26 | 11 | J. Moringen | ** Should be handled by next layer: |
| 27 | 11 | J. Moringen | **# Destroy participant |
| 28 | 11 | J. Moringen | **# Change configuration |
| 29 | 11 | J. Moringen | **# Re-create participant |
| 30 | 11 | J. Moringen | |
| 31 | 5 | J. Moringen | * Configuration mechanism has to be suitable for component layer (e.g. CCA) |