Boost

boost@lists.boost.org

May 2024

49 participants
27 discussions

Compression libraries such as zlib and zstd ought to be first class boost libraries
by Nigel Stewart 05 May '24

05 May '24

Hello all, I've been having a fairly hard time enabling zlib and zstd for boost 1.85.0 so we can make use of the compression support in iostreams module. We do have some specifics - static linking, non-standard file names and not system-installed. Windows and Linux. For various reasons it looks like we're going to copy certain files into our modules, rather than puzzle over making this work. It's not ideal, but workable. But along the way it's become clear that this functionality is not first-class boost citizen. Such as the broken links in the documentation, and various historical questions via google reporting similar issues. There are also other copies of zlib in the beast tree, because it's obviously needed for HTTP stuff too. zstd too? So I did think that I should at least mention that zlib, zstd, bzip2 and xv-utils all ought to be promoted to first-class boost libraries even though the majority of the maintenance is coming from upstream. They ought to be part of the "big tarball" and enabled and built by default regardless of what happens to be installed on the system. The cmake stuff ought to "just work" the way it does for other boost modules. I'm not quite volunteering myself, but it seems like a start to pose the question. The developer experience could be significantly improved for this particular corner of things. - Nigel Stewart

7 24

Proposal for yet another MQTT library for Boost
by Takatoshi Kondo 01 May '24

01 May '24

Dear Boost Developers, I'd like to propose a MQTT library to the Boost Libraries. Repository link: https://github.com/redboltz/async_mqtt Document link: https://redboltz.github.io/async_mqtt/doc/5.0.0/index.html Here is characteristics of async_mqtt: - C++17 or later is required. - async_mqtt supports Boost.Asio style completion tokens. - e.g. use_future, deferred, use_awaitable, callback functions, etc - Not only MQTT client but also MQTT server is supported. - User can use this library to develop MQTT broker. - Sample MQTT broker application is included. - Both MQTT v3.1.1 and v5.0 are supported. - In addition, undetermined protocol version is supported for server implementation. In this case, the protocol version is decided when you receive CONNECT packet. - Continuous packet sending - Users can send the next MQTT packets before the previous sending is not completed (completion handler is not invoked yet). - Auto acquiring/mapping topic alias is supported. - In addition, when resending a PUBLISH packet after reconnecting, the topic alias is removed and the original topic is restored. It is required by MQTT v5.0 spec. - Packet based send()/recv() APIs. - MQTT has various packets and some of their fields are optional. In order to keep simple APIs, async_mqtt uses packet based APIs. - See https://redboltz.github.io/async_mqtt/doc/5.0.0/tutorial/send_recv.html - Layered archtecture - async_mqtt can have predefined TCP, TLS, WS, WSS, and user defined underlying layer. Users can access the underlying layer using next_layer() member function of MQTT endpoint. So you can configure any layers by yourself. e.g. tcp_no_delay, set send/recv buffer size, etc - See https://redboltz.github.io/async_mqtt/doc/5.0.0/tutorial/create_endpoint.ht… - High performance - See https://redboltz.github.io/async_mqtt/doc/5.0.0/performance.html Background I have developed another mqtt library mqtt_cpp https://github.com/redboltz/mqtt_cpp since 2015. It is widely used but has some limitations. For example: - The functions are directly mapped to packets(publish, subscribe, etc), so optional features are not designed cleanly. - Due to set_publish_hander / on_publish style handler design, Completion Token cannot be supported. Based on this 9years experience, I designed the new MQTT library. This is async_mqtt. I would appreciate if you could endorse this library. Regards, Takatoshi Kondo

3 4