Services/Roadmaps/Server/Config
Status
| Configuration Library | |
| Stage | Draft |
| Status | In progress |
| Release target | ` |
| Health | OK |
| Status note | ` |
{{#set:Feature name=Configuration Library
|Feature stage=Draft |Feature status=In progress |Feature version=` |Feature health=OK |Feature status note=` }}
Team
| Product manager | ` |
| Directly Responsible Individual | ` |
| Lead engineer | ` |
| Security lead | ` |
| Privacy lead | ` |
| Localization lead | ` |
| Accessibility lead | ` |
| QA lead | ` |
| UX lead | ` |
| Product marketing lead | ` |
| Operations lead | ` |
| Additional members | ` |
{{#set:Feature product manager=`
|Feature feature manager=` |Feature lead engineer=` |Feature security lead=` |Feature privacy lead=` |Feature localization lead=` |Feature accessibility lead=` |Feature qa lead=` |Feature ux lead=` |Feature product marketing lead=` |Feature operations lead=` |Feature additional members=` }}
Open issues/risks
`
Stage 1: Definition
1. Feature overview
The Services Platform should have a single approach to the generation of a configuration dictionary that allows the user to get all their instance's data into a central location with a minimum of effort. It should also be structured in a way that allows for intuitive access to sections of the configuration by callable modules that handle specific tasks.
2. Users & use cases
This is a core component of the server. Baseapp will be the main consumer, getting the entire configuration, then portioning out appropriate pieces to the modules being loaded. In general, __init__ methods on classes should extract the pieces of their subdictionaries and assign them to variables as needed, though they can keep their own dictionary intact if they like.
3. Dependencies
`
4. Requirements
The config object should feel as close to a python dictionary as possible, while implementing a 2-level approach to data storage.
Non-goals
`
Stage 2: Design
5. Functional specification
Config files are of the form:
\[<section>\] <key> = <value> (Arrays are specified with additional <value>s on new lines)
Additional files can be included with the "extends" keyword: the file given as a value is also read into the configuration.
Items that are not part of a header will be considered to be in the "default" section. Any extended files will also start in the main namespace, though it is expected that they will have their own sections.
Legal characters for the section field are: [A-Za-z0-9_]
The Config object will have the following methods:
__init__(seed = None): Read in the filename corresponding at the location and generate the dictionary from that. If seed is None, begin with an empty config object. The parser will follow any "extends" keywords.
extend(section, newdict): Adds the k/v pairs in newdict to the config under section. Will overwrite any previously existing key at section.key, but will not remove already existing keys in that section that are not directly overwritten.
sections(): returns a list of sections in the config
section(sectionname): returns a dict of k/v pairs that correspond to that section of the config file.
delete(section, key=None): deletes the value at section.key, or the entire section if key is None.
get(key, default=None, section=None): standard dict get semantic, extended to handle sections.
set(key, value, section=None): standard dict set, extended to cover sections
6. User experience design
N/A
Stage 3: Planning
7. Implementation plan
`
8. Reviews
Security review
`
Privacy review
`
Localization review
`
Accessibility
`
Quality Assurance review
`
Operations review
`
Stage 4: Development
9. Implementation
`
Stage 5: Release
10. Landing criteria
` {{#set:Feature open issues and risks=` |Feature overview=The Services Platform should have a single approach to the generation of a configuration dictionary that allows the user to get all their instance's data into a central location with a minimum of effort. It should also be structured in a way that allows for intuitive access to sections of the configuration by callable modules that handle specific tasks. |Feature users and use cases=This is a core component of the server. Baseapp will be the main consumer, getting the entire configuration, then portioning out appropriate pieces to the modules being loaded. In general, __init__ methods on classes should extract the pieces of their subdictionaries and assign them to variables as needed, though they can keep their own dictionary intact if they like. |Feature dependencies=` |Feature requirements=The config object should feel as close to a python dictionary as possible, while implementing a 2-level approach to data storage. |Feature non-goals=` |Feature functional spec=Config files are of the form:
\[<section>\] <key> = <value> (Arrays are specified with additional <value>s on new lines)
Additional files can be included with the "extends" keyword: the file given as a value is also read into the configuration.
Items that are not part of a header will be considered to be in the "default" section. Any extended files will also start in the main namespace, though it is expected that they will have their own sections.
Legal characters for the section field are: [A-Za-z0-9_]
The Config object will have the following methods:
__init__(seed = None): Read in the filename corresponding at the location and generate the dictionary from that. If seed is None, begin with an empty config object. The parser will follow any "extends" keywords.
extend(section, newdict): Adds the k/v pairs in newdict to the config under section. Will overwrite any previously existing key at section.key, but will not remove already existing keys in that section that are not directly overwritten.
sections(): returns a list of sections in the config
section(sectionname): returns a dict of k/v pairs that correspond to that section of the config file.
delete(section, key=None): deletes the value at section.key, or the entire section if key is None.
get(key, default=None, section=None): standard dict get semantic, extended to handle sections.
set(key, value, section=None): standard dict set, extended to cover sections |Feature ux design=N/A |Feature implementation plan=` |Feature security review=` |Feature privacy review=` |Feature localization review=` |Feature accessibility review=` |Feature qa review=` |Feature operations review=` |Feature implementation notes=` |Feature landing criteria=` }}
Feature details
| Priority | Unprioritized |
| Rank | 999 |
| Theme / Goal | ` |
| Roadmap | ` |
| Secondary roadmap | ` |
| Feature list | ` |
| Project | ` |
| Engineering team | ` |
{{#set:Feature priority=Unprioritized
|Feature rank=999 |Feature theme=` |Feature roadmap=` |Feature secondary roadmap=` |Feature list=` |Feature project=` |Feature engineering team=` }}
Team status notes
| status | notes | |
| Products | ` | ` |
| Engineering | ` | ` |
| Security | ` | ` |
| Privacy | ` | ` |
| Localization | ` | ` |
| Accessibility | ` | ` |
| Quality assurance | ` | ` |
| User experience | ` | ` |
| Product marketing | ` | ` |
| Operations | ` | ` |
{{#set:Feature products status=`
|Feature products notes=` |Feature engineering status=` |Feature engineering notes=` |Feature security status=` |Feature security health=` |Feature security notes=` |Feature privacy status=` |Feature privacy notes=` |Feature localization status=` |Feature localization notes=` |Feature accessibility status=` |Feature accessibility notes=` |Feature qa status=` |Feature qa notes=` |Feature ux status=` |Feature ux notes=` |Feature product marketing status=` |Feature product marketing notes=` |Feature operations status=` |Feature operations notes=` }}