123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475 |
- [/
- Copyright (c) 2016-2019 Vinnie Falco (vinnie dot falco at gmail dot com)
- Distributed under the Boost Software License, Version 1.0. (See accompanying
- file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
- Official repository: https://github.com/boostorg/beast
- ]
- [section Design Choices]
- The implementations were originally driven by business needs of cryptocurrency
- server applications (e.g. [@https://github.com/ripple/rippled rippled]),
- written in C++. These needs were not met by existing solutions so Beast
- was written from scratch as a solution. Beast's design philosophy avoids
- flaws exhibited by other libraries:
- * Don't try to do too much.
- * Don't sacrifice performance.
- * Mimic __Asio__; familiarity breeds confidence.
- * Role-symmetric interfaces; client and server the same (or close to it).
- * Leave important decisions, such as allocating memory or
- managing flow control, to the user.
- Beast uses the __DynamicBuffer__ concept presented in the __NetTS__,
- and relies heavily on the __ConstBufferSequence__ and
- __MutableBufferSequence__ concepts for passing buffers to functions.
- The authors have found the dynamic buffer and buffer sequence interfaces to
- be optimal for interacting with Asio, and for other tasks such as incremental
- parsing of data in buffers (for example, parsing websocket frames stored
- in a [link beast.ref.boost__beast__static_buffer `static_buffer`]).
- During the development of Beast the authors have studied other software
- packages and in particular the comments left during the Boost Review process
- of other packages offering similar functionality. In this section and the
- FAQs that follow we attempt to answer those questions that are also applicable
- to Beast.
- For HTTP we model the message to maximize flexibility of implementation
- strategies while allowing familiar verbs such as [*`read`] and [*`write`].
- The HTTP interface is further driven by the needs of the WebSocket module,
- as a WebSocket session requires a HTTP Upgrade handshake exchange at the
- start. Other design goals:
- * Keep it simple.
- * Stay low level; don't invent a whole web server or client.
- * Allow for customizations, if the user needs it.
- The following video presentation was delivered at
- [@https://cppcon.org/ CppCon]
- in 2016. It provides a light introduction to some of the earliest
- interfaces of Beast (which have since changed).
- [/ "Introducing Beast..."]
- [block'''
- <mediaobject>
- <videoobject>
- <videodata fileref="https://www.youtube.com/embed/uJZgRcvPFwI?rel=0"
- align="center" contentwidth="560" contentdepth="315"/>
- </videoobject>
- </mediaobject>
- ''']
- [include 1_http_message.qbk]
- [include 2_http_comparison.qbk]
- [include 3_websocket_zaphoyd.qbk]
- [include 4_faq.qbk]
- [endsect]
|