Re: [boost] [review][beast] Review of Beast starts today : July 1 - July 10

Subject: Re: [boost] [review][beast] Review of Beast starts today : July 1 - July 10
From: Vinícius dos Santos Oliveira (vini.ipsmaker_at_[hidden])
Date: 2017-07-09 16:55:35

2017-07-03 23:17 GMT+02:00 Vinnie Falco via Boost <boost_at_[hidden]>:

> The question is, can Beast be written against generic concepts which
> define synchronous and asynchronous operations over buffer oriented
> streams, instead of being tied to Boost.Asio?
>
> First lets imagine what such generic concepts might look like,
> independent of Beast. We will start with the synchronous case which is
> the easiest.
>
> In the code which follows:
>
>     * `Stream` is a type representing a buffer oriented I/O stream
>
>     * `Buffers` is type representing an ordered sequence of zero
>       or more non-owning references to contiguous octet buffers
>
>     * `Error` is type representing an error code
>
> The following synchronous stream operations are defined:
>
>     /** Read data from a stream synchronously
>        `stream` The stream to read from
>        `buffers` The buffers to read into
>        `error` Set to the error if any occurred.
>         returns: The number of bytes transferred, or 0 on error.
>     */
>     std::size
>     read(
>         Stream& stream,
>         Buffers const& buffers,
>         Error& error);
>
>     /** Write data to a stream synchronously
>         `stream The stream to write to
>         `buffers The buffers to write from
>         `error` Set to the error if any occurred.
>         returns: The number of bytes transferred, or 0 on error.
>     */
>     std::size_t
>     write(
>         Stream& stream,
>         Buffers const& buffers,
>         Error& error);
>
> This looks pretty generic

No, this looks overly complicated, plain and simple.

For the Asio-dependant part, just keeping the current design. For the Asio
not-dependant part, you should avoid a parser that is too smart. You
researched too little on this topic.

Even Asio prefer a proactor design rather than reactor design. This
callback-for-every-token-read/framework design is the reason for all this
complicated design.

Look how to design a HTTP parser without templates and keeping all
“generic” properties you wish to achieve:
https://github.com/BoostGSoC14/boost.http/blob/b00380a1f8c2588baa4cd5732460624b80f23a1f/include/boost/http/reader/request.hpp#L36

Design was mostly inspired by this talk:
https://vimeo.com/channels/ndcoslo2016/171704565 (kudos to Bjorn for
pointing me to this excellent talk)

I'd to write more proper replies, but given my appeal to 4 more days was
left unanswered, I need to do my tricks to save time.

-- 
Vinícius dos Santos Oliveira
https://vinipsmaker.github.io/