2 Ideas
David Sugar edited this page 6 months ago

Ideas and plans for discussion.

Local Docs

A lot is done in generated documentation. This includes shortcut links to project management, as well as project api documentation, and all other documentation too. Developers should make greater use of this resource.

To help do that, perhaps the answer is to add a cmake target to generate or update the Doxyfile docs, and also open the local web browser pointing to the generated docs. The near equivalent feature is found in godoc. This is by far the handiest project resource, and it is the most hidden currently.

Replace MQTT with ZMQ

One of the disadvantages of ZMQ is that it is written in C++, and so pulls a C++ runtime into a project, even if the api is then reduced to C. This is not an issue for my work because my core services are already written in C++.

ZMQ also removes the need for a separate broker, because Bordeaux could be its own messaging broker. It offers a cloudsafe security and authentication model often missing in MQTT.

There is to be ZMQ signaling and possible media modules for integration with Calypso already, so I would be doing other ZMQ work, and I may chose to vendor it to support that.

For IPC use, it is easily cross platform, as well as offering a secure low latency network accessible IPC that can operate securely and seems more ideal for transactional micro-services than http.

For IoT devices, it does have a simple API, and it would not impact footprint much if the supporting services are also written in C++.

Semi generic utils

Generic utilities with some specialization for use with our VoIP servers. A typical example would be a sip message injection utility which might be used stand-alone alternative to message injection from Bordeaux, or a sip ping. Utilities like this may also be built and used more cross-platform than the server itself may be, but also are built for specific protocols, so there is a potential mission and deployment mismatch in this.

Some utilities that might make more sense may simply be media processing ones, which have no connection to specific drivers, but do relate to Bordeaux itself. An example is something like the old Bayonne audiotool.

Vendoring eXosip2

To create a smaller footprint and improve portability we could vendor eXosip, especially for static linking, without tls support. Many Bordeaux uses are local side infrastructure only, and this really only requires tcp or udp sip, not tls. We could also disable building srv support and other complicated or specialized eXosip features that are unneeded for Bordeaux, especially in statically built drivers. This also would make Bordeaux easier to acquire, build at least sip support, and use on most systems.

Requirements

This currently would require both vendoring osip/eXosip for small static builds, and patching the vendor'd source for sha hash support for a non-openssl builds of eXosip (this may appear in eXosip 5.2.1). This would likely be done in osip2, which already duplicates the libcrypto md5 code, or by linking libcrypto for static builds for sha support.

Vendoring fmtlib

There is a lot of places we do string to/from number conversions, even inside the ccscript engine. The traditional ansi c/c++ conversion functions are not very optimized.

Fmtlib is not being well maintained on Debian, so we would have to vendor at least for that. Using fmtlib could improve runtime execution performance of the Bordeaux engine. It also would be needed to introduce other integrated services, such as RESTinio. Finally, it is compatible with c++20 proposed fmt support.