|
14 | 14 |
|
15 | 15 | Key-value Storage
|
16 | 16 | #################
|
| 17 | + |
| 18 | +- Key-Value Storage is needed because there are (legacy) applications which require a KVS |
| 19 | +- There are multiple Key-Value Storages allowed per application |
| 20 | +- There must be an update mechanism from different versions of a KVS to another version |
| 21 | +- When are modifications persisted? Configurable? |
| 22 | +- The same KVS should be read/writeable from C++ & Rust. |
| 23 | +- Supported Datatypes: Primitive Datatypes & Non-Primitive Datatypes; To be coordinated with IPC/Communication CTF, to use the same datatypes |
| 24 | +- Tooling to modify/access content of KVS "from the outside" |
| 25 | +- KVS should store default values |
| 26 | +- Integrity of the KVS should be checked |
| 27 | + |
| 28 | +.. document:: [Your Feature Name] |
| 29 | + :id: DOC__Your_Feature_Name |
| 30 | + :status: draft |
| 31 | + :safety: ASIL_D |
| 32 | + :tags: contribution_request, feature_request |
| 33 | + |
| 34 | +.. attention:: |
| 35 | + The above directive must be updated according to your Feature. |
| 36 | + |
| 37 | + - Modify ``name`` to be your Feature Name |
| 38 | + - Modify ``id`` to be your Feature Name in upper snake case preceded by ``DOC_`` |
| 39 | + - Adjust ``status`` to be ``valid`` |
| 40 | + - Adjust ``asil`` according to your needs |
| 41 | + - Extend ``tags`` according to your needs, but please keep two default tags there |
| 42 | + |
| 43 | + |
| 44 | +Feature flag |
| 45 | +============ |
| 46 | + |
| 47 | +To activate this feature, use the following feature flag: |
| 48 | + |
| 49 | +``experimental_[your_feature_name]`` |
| 50 | + |
| 51 | + .. note:: |
| 52 | + The feature flag must reflect the feature name in snake_case. Further, it is prepended with ``experimental_``, as |
| 53 | + long as the feature is not yet stable. |
| 54 | + |
| 55 | + |
| 56 | +Abstract |
| 57 | +======== |
| 58 | + |
| 59 | +[A short (~200 word) description of the contribution being addressed.] |
| 60 | + |
| 61 | + |
| 62 | +Motivation |
| 63 | +========== |
| 64 | + |
| 65 | +[Clearly explain why the existing platform/project solution is inadequate to address the topic that the Feature Request solves.] |
| 66 | + |
| 67 | + .. note:: |
| 68 | + The motivation is critical for Feature Requests that want to change the existing features or infrastructure. |
| 69 | + It should clearly explain why the existing solution is inadequate to address the topic that the Feature Request solves. |
| 70 | + Feature Request submissions without sufficient motivation may be rejected. |
| 71 | + |
| 72 | + |
| 73 | +Rationale |
| 74 | +========= |
| 75 | + |
| 76 | +[Describe why particular design decisions were made.] |
| 77 | + |
| 78 | + |
| 79 | + .. note:: |
| 80 | + The rationale should provide evidence of consensus within the community and discuss important objections or concerns raised during discussion. |
| 81 | + |
| 82 | + |
| 83 | +Specification |
| 84 | +============= |
| 85 | + |
| 86 | +[Describe the requirements, architecture of any new feature.] or |
| 87 | +[Describe the change to requirements, architecture, implementation, process, documentation, infrastructure of any change request.] |
| 88 | + |
| 89 | + .. note:: |
| 90 | + A Feature Request shall specify the stakeholder requirements as part of our platform/project. |
| 91 | + Thereby the :need:`RL_technical_lead` will approve these requirements as part of accepting the Feature Request (e.g. merging the PR with the Feature Request). |
| 92 | + |
| 93 | + |
| 94 | +Backwards Compatibility |
| 95 | +======================= |
| 96 | + |
| 97 | +[Describe potential impact (especially including safety and security impacts) and severity on pre-existing platform/project elements.] |
| 98 | + |
| 99 | + |
| 100 | +Security Impact |
| 101 | +=============== |
| 102 | + |
| 103 | +[How could a malicious user take advantage of this new feature?] |
| 104 | + |
| 105 | + .. note:: |
| 106 | + If there are security concerns in relation to the Feature Request, those concerns should be explicitly written out to make sure reviewers of the Feature Request are aware of them. |
| 107 | + |
| 108 | + |
| 109 | + |
| 110 | +Safety Impact |
| 111 | +============= |
| 112 | + |
| 113 | +[How could the safety be impacted by the new feature?] |
| 114 | + |
| 115 | + .. note:: |
| 116 | + If there are safety concerns in relation to the Feature Request, those concerns should be explicitly written out to make sure reviewers of the Feature Request are aware of them. |
| 117 | + ToDo - Link to the Safety Impact Method |
| 118 | + |
| 119 | +[What is the expected ASIL level?] |
| 120 | +[What is the expected classification of the contribution?] |
| 121 | + |
| 122 | + .. note:: |
| 123 | + Use the component classification method here to classfiy your component, if it shall to be used in a safety context: (TODO: add link to component classification). |
| 124 | + |
| 125 | + |
| 126 | +License Impact |
| 127 | +============== |
| 128 | + |
| 129 | +[How could the copyright impacted by the license of the new contribution?] |
| 130 | + |
| 131 | + |
| 132 | +How to Teach This |
| 133 | +================= |
0 commit comments