openbmc/bmcweb/DEVELOPING.md

7 As OpenBMC is intended to be deployed on an embedded system, care should be
11 - Binaries and static files should take up < 1MB of filesystem size
12 - Memory usage should remain below 10MB at all times
13 - Application startup time should be less than 1 second on target hardware
18 Care should be taken to ensure that all code is written to be asynchronous in
21 should be avoided if possible, and instead use async tasks within boost::asio.
25 Secure coding practices should be followed in all places in the webserver
31 - All input from outside the application is considered untrusted, and should be
35 - Where applicable, noexcept methods should be preferred to methods that use
37 - Explicitly bounded types should be preferred over implicitly bounded types
44 Error handling should be constructed in such a way that all possible errors
54   should be filed as a bug
56 Where possible, 307 and 308 redirects should be avoided, as they introduce the
65   explicitly intended to be runtime configurable, its logic should be "baked in"
67   configurable at runtime, the default values should be included in application
80   of exceptions should be cases where the program can be reasonably expected to
119 Abstraction and Interface guarantees should be used when multiple
126 The webserver should be capable of hosting webui-vue, and implementing the
127 required flows to host the application. In general, all access methods should be
135 updated. OEM schemas should conform and be developed in line with the rules in
147 Project commit message formatting should be obeyed
150 Commit messages should answer the following questions:
153   adding new functionality should include statements about how the commit in
157   resources, and new or changed properties. Any route changes should be
164 Commit messages should be line wrapped 50/72.
171 The kernel has very similar rules around compatibility that we should aspire to
220   traffic. "critical" should be used when bmcweb encountered an event or entered
224   response. Service is still operational. "error" should be used for unexpected