Services/Roadmaps/Server/Config

From MozillaWiki
Jump to: navigation, search
Please use "Edit with form" above to edit this page.

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 ` `