July 2017 - Boost - lists.boost.org

[beast] Review
by Marcel Ebmer 07 Jul '17

07 Jul '17

Here's my Review: DESIGN ====== The design of concepts, data structures and algorithms is mostly done well, with only minor concerns: - The smell of two-phase initialization. Required message properties like method and target have to be set from outside. This makes me as a library user afraid of forgetting something vital. The same holds for prepare_payload(). If I forget to call prepare_payload() or forget to set one of the required message properties or fields, my program may - in the worst case - appear to work correctly. - Inconsequent application of automagic. WebSocket control frames are automagically responded to. Iff there's an active read(). Basically, having an active read() at almost all times is a requirement of any correct program using Beast. Even though I enjoy the help from the library, and the requirement is usually met, I found this specific behaviour to be inconsequent. Also, the very first WebSocket example in the docs makes it clear that while a close from the peer is handled automagically under the above condition, a close from my side is quite tedious to write. There should be a utility in the library to do the draining for me. - The naming of BodyReader and BodyWriter initially got me confused. In my mind, I 'read' a body FROM a stream/buffer, I 'write' it INTO a stream or buffer. The library uses the terms in the reverse sense. This is not incorrect of course, but my initial confusion may be a sign of suboptimal naming. IMPLEMENTATION ============== Didn't look in-depth. DOCUMENTATION ============= The documentation is very well structured. It is complete in many, but not all places. - A minimalistic HTTP server example would have helped me get started. Just something very, very basic. Reply to each request with "your request was". - In some places, non-self-explanatory function names suddenly pop up without being first introduced. For example, in the section "Using WebSocket"."Send and Receive Messages", text() and got_text() could use some explanation. In the same section, the reference to set_option() seems out-of-place and makes me wonder what I missed. - Since the documentation features comparison with other libraries, it may be worth comparing pion (https://github.com/splunk/pion) as well. - Many reference pages could use some prosaic explanation. For example, my uncertainty concerning message.prepare_payload() might have been alleviated, were it more clear what the function is intended for and what the effect of omitting it would be. SCOPE ===== Since the FAQ is quite defensive in regard to the library's scope, I feel this is worth some discussion. I found the scope to be just right for now, but with future potential. As it is, the library takes away all the tedious protocol stuff, while leaving all important design decisions to the user. It feels like an extension to ASIO. However, there's no apparent reason why (e.g.) request targets shouldn't be URL-decoded, and why form data should not be parsed into a map of some kind. The way I see it, none of this added funtionality would interfere with the library's design. It would, however, make the library user's life a whole lot easier, and probably attract more users as well. USEFULNESS ========== See SCOPE. Very valuable, could be even better. HOW MUCH EFFORT & TRIED TO USE ============================== I invested about a day into the review, read the documentation and ported a small REST-like service from pion to Beast. I may be biased towards Beast due to temporal proximity, but I feel the latter made the code easier to reason about and, at the very least, did not hurt performance. I used gcc 7.1 and clang 4.0. On the review branch, none of the two had any issues. I deliberately did NOT follow the discussion on the mailing list, in order to remain as unbiased as practicable. HOW KNOWLEDGABLE AM I? ====================== I have worked on several HTTP servers and experimented with writing an HTTP server library a few years back. I have no practical experience with WebSockets. IN ONE SENTENCE =============== Beast should be ACCEPTED into Boost. Marcel

2 3

[build] No output until an action completes?
by Tom Westerhout 07 Jul '17

07 Jul '17

Greetings! I've run into a problem that a Boost.Build action produces no output until the command returns. For example, in my Jamfile I have rule do-measure ( test-name : sources * : requirements * ) { ... some preparation work ... } actions do-measure { $(COMMAND) $(ARGS) } notfile ha : @do-measure : ... : ... ; COMMAND is a Python script that runs for a long time and produces some debug information. But b2 does not print this output until COMMAND returns. This is really unfortunate because Travis requires a command to produce output at least once per 10 mins or something. Otherwise it thinks the command has stalled and terminates it. Is there some configuration parameter or a trick to make b2 print the debug info COMMAND produces? or maybe some dummy output so that Travis allows it to run longer than 10 mins? Any help is highly appreciated! Tom

2 2

Serialization support for small_vector
by Brian Wood 07 Jul '17

07 Jul '17

Shalom I've added support for small_vector to the C++ Middleware Writer. While testing the support, I got a warning about dereferencing a type-punned pointer breaking strict-aliasing rules. That was on line 340 of small_vector.hpp. I was using g++ 7.1 on FreeBSD/ TrueOS. I used the following "Middle" code for testing: message-lengths variable example_messages -out (message_id_8, ::boost::container::small_vector<int32_t,30>) -in (::boost::container::small_vector<int32_t,30>) } >From what I could tell the serialization/deserialization worked fine. If small_vector were broken out into a separate library that would be helpful from my perspective. It would make it easier for me to add small_vector to my example code. Brian Ebenezer Enterprises - In G-d we trust. http://webEbenezer.net

1 0

[CallableTraits] Review results
by Louis Dionne 07 Jul '17

07 Jul '17

Dear Boost, I am pleased to announce that the CallableTraits library is CONDITIONALLY ACCEPTED into Boost. I counted the following formal reviews: - Bruno Dutra: Yes - Emil Dotchevski: Yes - John P. Fletcher: Yes - Klemens Morgenstern: Yes - Peter Dimov: Yes - Zach Laine: Yes The following people also participated to the review by providing informal feedback: - Edward Diener - Gavin Lambert - Niall Douglas - Paul Fultz II - Tim Song I also based my decision on previous experience I've had using the library, and some issues we faced in the Standard Committee where we could have used CallableTraits. I'd like to thank everyone who participated to the review for their feedback, and also Barrett Adair for his submission. The following lists the conditions for acceptance, and also summarizes the general feedback received during the review. GitHub issues are leveraged to make the tracking of these comments easier. Below, whenever I refer to #XYZ, the corresponding ticket can be found at https://github.com/badair/callable_traits/issues/XYZ To see all the issues that were discussed during the review, you can search for tickets labeled with `review` on GitHub (please allow some time for Barrett to update the new issues I just filed): https://github.com/badair/callable_traits/issues?page=1&q=+label%3Areview Conditions for acceptance ------------------------- The following are points that must be addressed for the library to be accepted. Once all of the associated GitHub issues are closed, I ask that the author post to this list with links to the closed issues. Unless major problems (having to do with the closed issues) are raised at that time, the library will be automatically accepted into Boost, no additional review required. - The library needs to clearly document the advantages of CallableTraits over FunctionTypes. Concrete examples must be given (at least one, preferably two). See #117. - The level of C++ conformance required for the whole library needs to be clearly stated in the documentation. Individual components should only document divergences from that base level of conformance. The current state of things is quite confusing for users. See #118. - The "algorithmic" parts of the library must be removed, since they are out of scope. This has already been partly done in issue #114, but the following algorithms must be discussed too (let's follow up in #114): + args_at + clear_args + pop_front_args + push_front_args + expand_args_right + expand_args_left - The lazy metafunctions and predicate traits should be SFINAE-friendly, just like the aliases are. I think this inconsistency is a big deal, enough to be a condition for acceptance. See #134. Summary of the feedback received -------------------------------- The following is a compilation of other points that were made during the review, but which are not requirements for acceptance. I trust, but do not require, that all of those points will be considered by the author: - There is a loss of information with the `args` metafunction. For example, `void(T)` and `void(T, ...)` both give the same result. See #132. - Consider adding a way of obtaining the parameter list of a function without the type of `*this`. See #133. - The documentation uses the terms of art "implementation defined" and "undefined behavior" incorrectly. See #103 and #131. - The non-reference documentation should present at least one real-world use case. See #116. - The library should handle top-level cv-qualifiers. See #106. - Consider supporting different calling conventions (e.g. `__cdecl`). See #102. - Consider adding a pre-C++17 implementation of `is_invocable` and friends. See #119. - The documentation should clearly state that the library can be used without the rest of Boost. See #99. - Consider combining `expand_args` and `args` into a single metafunction with a default "output" parameter of `std::tuple`. See #126. - Consider adding `make_fn` and `make_mem_fn` metafunctions to construct a signature from a return type and a tuple of the arguments. See #113. - Consider renaming some traits, like `is_reference_member`. See #108. - Reword some parts of the documentation that look odd due to the use of passive tense. See #105. - Consider adding a version of `apply_member_pointer` which carries cv-qualifiers. See #138. - Consider adding `remove_member_cv_ref` and `copy_member_cv_ref`. See #139. - Why does `qualified_parent_class_of` always returns a const& for PMDs? See #112. - Why does `qualified_parent_class_of` return a ref-qualified type even for unqualified PMFs? See #112. A few of my own comments: - Consider using alphabetical order in the table of contents of the reference. See #135. - Consider renaming `apply_member_pointer` to something like `make_member`. See #136. - Consider dropping the `parent_` in `parent_class_of`, or adding a note to justify the name. See #137. Again, thanks to everyone who participated in the review, and congratulations to Barrett for his work! Regards, Louis Dionne

2 3

[beast] Chunking example
by Bjorn Reese 07 Jul '17

07 Jul '17

How would an example of receiving a chunked transfer using the synchronous API look? In pseudo-code, I want to do as follows: establish connection while not closed read chunk print chunk

4 25

Boost Master branch is now closed for the beta
by Marshall Clow 07 Jul '17

07 Jul '17

Except with explicit permission by a release manager. Do whatever you want on develop, just don't change master. We'll re-open master after the beta. -- Marshall Upcoming release schedule: 8-Jul: Boost 1.65.0 closed for all changes 12-Jul: Boost 1.65.0 beta; master branch re-opened 2-Aug: Release closed for all changes, except by permission of a release manager. 5-Aug: Boost 1.65.0 closed for all changes 9-Aug: Boost 1.65.0 release -- Marshall

4 3

Fwd: [review][beast] Review of Beast
by Michael Caisse 06 Jul '17

06 Jul '17

I received this review as a private email from Stanislav who has indicated that I may share it on the list. -------- Forwarded Message -------- Subject: [boost] [review][beast] Review of Beast Date: Thu, 6 Jul 2017 20:23:26 +0300 From: Stanislav Karchebnyy <hidden> To: mcaisse-lists(a)ciere.com Good day! I'm not a very good writer in english, so i tried to keep it short and to the point. - What is your evaluation of the design? I believe it fits well with asio style. - What is your evaluation of the implementation? I like the modularity and composability of the library, e.g. various buffers that comply with asio interfaces. Also use of helpful typedefs makes code a lot easier to read. Code style is almost declarative (which is a good sign in my book). - What is your evaluation of the documentation? Documentation is good, although some methods are documented a little short and a bit tautologically. This is not specific to beast however, seen it in many other boost libraries. - What is your evaluation of the potential usefulness of the library? It is immensely useful as it is already. See below for the example. - Did you try to use the library? With which compiler(s)? Did you have any problems? Currently I’m developing with Beast on latest OSX with clang. It compiles cleanly and runs quite well. The aim is to later use it also on Linux with gcc. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I’m in process of converting our POCO-based networking code for HTTP/HTTPS client and Websocket client to Beast. I started with Websocket and it was a pleasant and rather quick conversion from POCO-style ActiveDispatcher methods (which are ugly with binds and tuples for argument packs) to truly asynchronous beast websocket implementation. We use own protocol running on top of websocket frames, and with beast it was really easy to implement. That beast is a construction framework and does not have unnecessary boilerplate made it quite easy to plug our own parsing engine directly on top of websocket frames. Code became much cleaner as a result. I did not do speed benchmarking yet, as I’m still in development phase, but I’m much more concerned about maintainability in this project and beast made it a lot better - unfortunately I cannot share the code, but now I can trace the state transitions with a glance, instead of digging through bunch of POCO tuple-ridden methods. Another improvement is the fact that POCO websocket uses a dedicated listener thread for input, while beast utilises proper asio design. Beast comes with quite good examples, that covered about 90% of my questions during transition, the rest was answered by Vinnie himself. He is very responsive and helpful as a library maintainer. - Are you knowledgeable about the problem domain? Yes, I know how http and websocket things are supposed to work. My overall impression with the library and its author helpfulness suggests that ACCEPT to boost is a reasonable move. -- Sr. Software Engineer twilio <http://www.twilio.com/?utm_source=email_signature> EMAIL hidden

1 0

[beast] Response alias?
by Bjorn Reese 06 Jul '17

06 Jul '17

Is it possible to provide a HTTP 200 response alias for Beast? This is needed for SHOUTcast internet radio servers. See for instance: https://curl.haxx.se/libcurl/c/CURLOPT_HTTP200ALIASES.html

2 1

string_view versus string_ref
by Andrzej Krzemienski 06 Jul '17

06 Jul '17

Hi Everyone, I would like to understand the situation with these two templates: basic_string_view and basic_string_ref. The official, advertised library is string_ref: http://www.boost.org/doc/libs/1_64_0/libs/utility/doc/html/string_ref.html At the same time we have string_view: http://www.boost.org/doc/libs/1_64_0/boost/utility/string_view.hpp But the latter is never mentioned in the documentation, except in Boost.Log: (see http://www.boost.org/users/history/version_1_61_0.html) The support for boost::basic_string_ref and its specializations is > deprecated; users are encouraged to switch to boost::basic_string_view. > The support for boost::basic_string_ref will be removed in future > releases. > My question: is there any official position of Boost about having these two templates? Regards, &rzej;

4 3

[beast] Looking for ongoing Code Review!
by Vinnie Falco 05 Jul '17

05 Jul '17

Time for a realistic self-assessment. The feedback that I've gotten about Beast thus far has been pretty great, thanks to everyone for taking the time to get familiar with it. Seems like people are overall approving of the technical quality, but there is a recurring theme with the complaints. Specifically that there are small quality of life issues and deviations from best practices. For example, the two-phase initialization, missing verification on SSL client, verbose or missing examples, confusing or missing parts of documentation. Someone suggested that I solicit assistance from the list. I would like to have ongoing code review of everything in Beast before it gets merged. It would benefit the library greatly and thus benefit its users. As new features get developed ("in-scope" items such as file_body) having an extra set of eyes to make sure I don't do something silly or obviously unpleasant would be helpful. This also reduces the possibility that a future version of Beast may require a breaking change. I'm looking for volunteers to provide regular ongoing code review of branches in Beast's pull request queue! I realize this is a big ask, especially because I have a knack for producing quite a bit of code and change over time. Still, its worth asking. Ideally this review will come from stakeholders (i.e. users of the library). Any Beast users who are out there, please consider participating in code reviews. Its easy just subscribe to the repository using the button on the right of its GitHub page and then when you see new pull requests jump in there and add comments on anything you love/hate. I'll take whatever I can get though, so anyone is welcome! Email me if you want to discuss it, <vinnie.falco(a)gmail.com> or just open an issue on the repository: <https://github.com/vinniefalco/Beast> Thanks! |

1 0