1[/ 2 Copyright (c) 2016-2019 Vinnie Falco (vinnie dot falco at gmail dot com) 3 4 Distributed under the Boost Software License, Version 1.0. (See accompanying 5 file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) 6 7 Official repository: https://github.com/boostorg/beast 8] 9 10[section Design Choices] 11 12The implementations were originally driven by business needs of cryptocurrency 13server applications (e.g. [@https://github.com/ripple/rippled rippled]), 14written in C++. These needs were not met by existing solutions so Beast 15was written from scratch as a solution. Beast's design philosophy avoids 16flaws exhibited by other libraries: 17 18* Don't try to do too much. 19 20* Don't sacrifice performance. 21 22* Mimic __Asio__; familiarity breeds confidence. 23 24* Role-symmetric interfaces; client and server the same (or close to it). 25 26* Leave important decisions, such as allocating memory or 27 managing flow control, to the user. 28 29Beast uses the __DynamicBuffer__ concept presented in the __NetTS__, 30and relies heavily on the __ConstBufferSequence__ and 31__MutableBufferSequence__ concepts for passing buffers to functions. 32The authors have found the dynamic buffer and buffer sequence interfaces to 33be optimal for interacting with Asio, and for other tasks such as incremental 34parsing of data in buffers (for example, parsing websocket frames stored 35in a [link beast.ref.boost__beast__static_buffer `static_buffer`]). 36 37During the development of Beast the authors have studied other software 38packages and in particular the comments left during the Boost Review process 39of other packages offering similar functionality. In this section and the 40FAQs that follow we attempt to answer those questions that are also applicable 41to Beast. 42 43For HTTP we model the message to maximize flexibility of implementation 44strategies while allowing familiar verbs such as [*`read`] and [*`write`]. 45The HTTP interface is further driven by the needs of the WebSocket module, 46as a WebSocket session requires a HTTP Upgrade handshake exchange at the 47start. Other design goals: 48 49* Keep it simple. 50 51* Stay low level; don't invent a whole web server or client. 52 53* Allow for customizations, if the user needs it. 54 55The following video presentation was delivered at 56[@https://cppcon.org/ CppCon] 57in 2016. It provides a light introduction to some of the earliest 58interfaces of Beast (which have since changed). 59 60[/ "Introducing Beast..."] 61[block''' 62<mediaobject> 63 <videoobject> 64 <videodata fileref="https://www.youtube.com/embed/uJZgRcvPFwI?rel=0" 65 align="center" contentwidth="560" contentdepth="315"/> 66 </videoobject> 67</mediaobject> 68'''] 69 70[include 1_http_message.qbk] 71[include 2_http_comparison.qbk] 72[include 3_websocket_zaphoyd.qbk] 73[include 4_faq.qbk] 74 75[endsect] 76