ExternalVendorCode/openmct
1
0
Fork 0
mirror of https://github.com/nasa/openmct.git synced 2025-02-21 01:42:31 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

[API] Fix markdown formatting

Browse Source
This commit is contained in:
Victor Woeltjen 2015-08-14 12:23:11 -07:00
parent f1bc15bf4f
commit 7ddaa4614b
1 changed files with 12 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
docs/src/design/proposals/APIRedesign.md
View File

@ -208,26 +208,26 @@ Other problems:
The following attributes of the current API are undesirable:
[ ] It is difficult to tell "where things are" in the code base.
[ ] It is difficult to see how objects are passed around at run-time.
[ ] Multiple interfaces for related concepts (e.g. telemetry) is confusing.
[ ] API documentation is missing or not well-formatted for use.
[ ] High-level separation of concerns is not made clear.
[ ] Interface depth of telemetry API is excessive (esp. `TelemetrySeries`)
[ ] Capabilities as a concept lack clarity.
[ ] Too many interfaces and concepts to learn.
- [ ] It is difficult to tell "where things are" in the code base.
- [ ] It is difficult to see how objects are passed around at run-time.
- [ ] Multiple interfaces for related concepts (e.g. telemetry) is confusing.
- [ ] API documentation is missing or not well-formatted for use.
- [ ] High-level separation of concerns is not made clear.
- [ ] Interface depth of telemetry API is excessive (esp. `TelemetrySeries`)
- [ ] Capabilities as a concept lack clarity.
- [ ] Too many interfaces and concepts to learn.
## Positive Features
It is desirable to retain the following features in an API redesign:
[ ] Creating new features and implementing them additively is well-supported.
[ ] Easy to add/remove features which involve multiple concerns.
- [ ] Creating new features and implementing them additively is well-supported.
- [ ] Easy to add/remove features which involve multiple concerns.
## Requirements
The following are considered "must-haves" of any complete API
redesign:
[ ] Don't require usage of Angular API.
[ ] Don't require support for Angular API.
- [ ] Don't require usage of Angular API.
- [ ] Don't require support for Angular API.