Services/Roadmaps/Server/Config
Status
Configuration Library | |
Stage | Draft |
Status | In progress |
Release target | ` |
Health | OK |
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 | ` |
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
`
Feature details
Priority | Unprioritized |
Rank | 999 |
Theme / Goal | ` |
Roadmap | ` |
Secondary roadmap | ` |
Feature list | ` |
Project | ` |
Engineering team | ` |
Team status notes
status | notes | |
Products | ` | ` |
Engineering | ` | ` |
Security | ` | ` |
Privacy | ` | ` |
Localization | ` | ` |
Accessibility | ` | ` |
Quality assurance | ` | ` |
User experience | ` | ` |
Product marketing | ` | ` |
Operations | ` | ` |