Development ========================== Vision and principles --------------------------- Consistency and coherence are one of the key characteristics of good software. While the reality is never black and white, it is important libcbor contributors are working towards the same high-level goal. This document attempts to set out the basic principles of libcbor and the rationale behind them. If you are contributing to libcbor or looking to evaluate whether libcbor is the right choice for your project, it might be worthwhile to skim through the section below. Mission statement ~~~~~~~~~~~~~~~~~~~~~~ *libcbor* is the compact, full-featured, and safe CBOR library that works everywhere. Goals ~~~~~~~~~~~~~~~~~~~~~~ RFC-conformance and full feature support ^^^^^^^^^^^^^^^^^^^^^^ Anything the standard allows, libcbor can do. **Why?** Because conformance and interoperability is the point of defining standards. Clients expect the support to be feature-complete and there is no significant complexity reduction that can be achieved by slightly cutting corners, which means that the incremental cost of full RFC support is comparatively small over "almost-conformance" seen in many alternatives. Safety ^^^^^^^^^^^^^^^^^^^^^^ Untrusted bytes from the network are the typical input. **Why?** Because it is the client expectation. Vast majority of security vulnerabilities are violations of contracts -- in other words, bugs -- anyway. Self-containment ^^^^^^^^^^^^^^^^^^^^^^ libcbor has no runtime dependencies. **Why?** Because any constraint imposed on libcbor has to be enforced transitively, which is difficult and leads to incompatibilities and distribution issues, especially in IoT applications. Portability ^^^^^^^^^^^^^^^^^^^^^^ If you can compile C for it, libcbor will work there. **Why?** Lowest-common-denominator solution for system-level and IoT software was the original niche of libcbor. Users who rely on libcbor expect future updates to work on their target platform. Stable and predictable API ^^^^^^^^^^^^^^^^^^^^^^ libcbor will not break without a warning. **Why?** `Industry-standard `_ versioning is a basic requirement for production-quality software. This is especially relevant in IoT environments where updates may be costly. Performance ^^^^^^^^^^^^^^^^^^^^^^ libcbor is fast and resource-efficient by design **Why?** Because the main maintainer is an avid hater of slow bloated software. Who wouldn't want more bang per their electricity buck? Non-goals ~~~~~~~~~~~~~~~~~~~~~~ - Convenience -- libcbor only provides the minimum surface to make it usable - FFI/SWIG/interop support -- libcbor is primarily a C library for C clients - One-off usecases support -- although there are primitives to reuse, the basic assumption is that most clients want most of CBOR features Development dependencies --------------------------- - `CMocka `_ (testing) - `Python `_ and `pip `_ (Sphinx platform) - `Doxygen `_ - `Sphinx `_ (documentation) - There are some `Ruby `_ scripts in ``misc`` - `Valgrind `_ (memory correctness & profiling) - `GCOV/LCOV `_ (test coverage) - `clang-format` Installing *sphinx* ~~~~~~~~~~~~~~~~~~~~~~ .. code-block:: bash pip install sphinx pip install sphinx_rtd_theme pip install breathe pip install https://github.com/lepture/python-livereload/archive/master.zip pip install sphinx-autobuild Further instructions on configuring advanced features can be found at ``_. Live preview of docs ~~~~~~~~~~~~~~~~~~~~~~ .. code-block:: bash cd doc make livehtml Set up git hooks ~~~~~~~~~~~~~~~~~ A catch-all git hook that runs clang-format and automatically refreshes the `GH pages `_ contents located in ``docs`` can be symlinked: .. code-block:: bash ln -sf $(pwd)/misc/hooks/pre-commit .git/hooks Testing and code coverage ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Please refer to :doc:`tests`