Re: Boost.Buffers: network-agnostic buffer types and algorithms

From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2023-02-06 23:31:15

On Mon, Feb 6, 2023 at 2:43 PM Gavin Lambert via Boost
<boost_at_[hidden]> wrote:
> Perhaps, though as I said I find the "optional is more fundamental"
> argument more compelling, so by that logic the compatibility code should
> be in serialization and not optional.

I just want to underscore that the question of "where does optional
go" is completely orthogonal to this proposed Boost.Buffers library,
and the buffers::source and buffers::sink interfaces in particular. My
proposed library has nothing to do with serialization and everything
to do with providing buffer-oriented interfaces.

In fact, buffers::source is more fundamental than serialization.
Boost.Serialization sits between buffers::source and the algorithm for
serialization of an optional. This diagram shows the relationship:

    { host } <---> Boost.Buffers <---> Boost.Serialization <---> { optional }

In this diagram "host" is the host program or library which is
implemented in terms of Boost.Buffer's abstract interfaces
(buffers::source for the case of using Boost.Serialization). As seen
in the diagram, the question of where the serialization spec for
"optional" goes, is unrelated to Boost.Buffers.

Another way to think of it is like this. If Boost.Serialization
implements the buffers::source interface, then any host which uses
Boost.Buffers will be able to make use of types archived through
Boost.Serialization. I'm not saying whether this is particularly
useful or not as that would depend on the specific use-case. For the
upcoming Boost.Http.Proto library, this means that anything which
defines a serialization for Boost.Serialization could be attached as
the body of an HTTP message.

The diagram for Boost.JSON looks different:

    { host } <---> Boost.Buffers <---> Boost.JSON

Here, if Boost.JSON wraps its existing streaming serializer for the
buffers::source interface then any Boost.Buffers-enabled host can make
use of JSON sources without depending on the Boost.JSON library.
There's a network effect at play; every library that enables
Boost.Buffers geometrically increases the utility of every other
library that uses Boost.Buffers. Furthermore, this scales to any
number of libraries and resolves the question of where the
buffers::sink (or buffers::source) algorithm goes. It goes in the
library which already implements a buffer-oriented data type. This
includes but is not limited to:

    * JSON
    * XML
    * Boost.Serialization archives
    * Mustache templates and output

Thanks