Re: [beast] A Networking-TS version of Boost.Asio and Boost.Beast is here!

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [beast] A Networking-TS version of Boost.Asio and Boost.Beast is here!

Boost - Dev mailing list
On Tue, Oct 3, 2017 at 9:40 AM, Vinnie Falco <[hidden email]> wrote:
> My preview of Boost.Asio version 1.66.0 is here:
>
> <https://github.com/vinniefalco/boost.asio/commits/net-ts>

Upon re-reading the message I realize that it might be confusing, so
to clarify - this is NOT an "official" version of Boost.Asio it is
just an experimental branch of what Boost.Asio might look like soon,
for anyone who wants to try out the latest stand-alone Asio features
in the Boost.Asio context.

Thanks

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [beast] A Networking-TS version of Boost.Asio and Boost.Beast is here!

Boost - Dev mailing list
On Tue, 2017-10-03 at 10:42 -0700, Vinnie Falco via Boost wrote:

> On Tue, Oct 3, 2017 at 9:40 AM, Vinnie Falco <[hidden email]> wrote:
> >
> > My preview of Boost.Asio version 1.66.0 is here:
> >
> > <https://github.com/vinniefalco/boost.asio/commits/net-ts>
> Upon re-reading the message I realize that it might be confusing, so
> to clarify - this is NOT an "official" version of Boost.Asio it is
> just an experimental branch of what Boost.Asio might look like soon,
> for anyone who wants to try out the latest stand-alone Asio features
> in the Boost.Asio context.

How do the Buffer concepts change to depend on networking? The way the buffers
are defined now, there is no dependency on Boost.Asio.


.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [beast] A Networking-TS version of Boost.Asio and Boost.Beast is here!

Boost - Dev mailing list
On Tue, Oct 3, 2017 at 2:23 PM, paul <[hidden email]> wrote:
> How do the Buffer concepts change to depend on networking? The way the buffers
> are defined now, there is no dependency on Boost.Asio.

Are you suggesting that the Net-TS buffer concepts do not depend on
Boost.Asio? That's not entirely correct.

Net-TS buffer sequence iterator value types must be convertible to
`std::experimental::net::const_buffer` or
`std::experimental::net::mutable_buffer`. In the Net-TS compatible
version of Asio these types are  `boost::asio::const_buffer` and
`boost::asio::mutable_buffer`.

There is simply no way to avoid the dependency on these concrete types
in Asio. In my other post I am proposing a library Boost.Buffers to
work around this problem, so that people (like me) can write libraries
which use only Asio buffer concepts, without a dependency on all of
Asio (and everything that Asio depends on, recursively).

Thanks

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [beast] A Networking-TS version of Boost.Asio and Boost.Beast is here!

Boost - Dev mailing list
On Wed, 2017-10-04 at 06:39 -0700, Vinnie Falco via Boost wrote:

> On Tue, Oct 3, 2017 at 2:23 PM, paul <[hidden email]> wrote:
> >
> > How do the Buffer concepts change to depend on networking? The way the
> > buffers
> > are defined now, there is no dependency on Boost.Asio.
> Are you suggesting that the Net-TS buffer concepts do not depend on
> Boost.Asio? That's not entirely correct.
>
> Net-TS buffer sequence iterator value types must be convertible to
> `std::experimental::net::const_buffer` or
> `std::experimental::net::mutable_buffer`. In the Net-TS compatible
> version of Asio these types are  `boost::asio::const_buffer` and
> `boost::asio::mutable_buffer`.

I see, that requirement comes from here: http://www.boost.org/doc/libs/1_65_1/
doc/html/boost_asio/reference/ConvertibleToConstBuffer.html


>
> There is simply no way to avoid the dependency on these concrete types
> in Asio. In my other post I am proposing a library Boost.Buffers to
> work around this problem, so that people (like me) can write libraries
> which use only Asio buffer concepts, without a dependency on all of
> Asio (and everything that Asio depends on, recursively).

Ideally, the constructor to `buffer` or `const_buffer` should take any class
that has a `.data()` and `.size()` member. This way `value_type` can fulfill
the requirement of `ConvertibleToBuffer` without needing the dependency on a
concrete type.

Another option, is just moving these concrete buffer classes from Asio to your
new library, and then Boost.Asio will depend on Boost.Buffers.



.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [beast] A Networking-TS version of Boost.Asio and Boost.Beast is here!

Boost - Dev mailing list
On Wed, Oct 4, 2017 at 7:51 AM, paul <[hidden email]> wrote:
> Ideally, the constructor to `buffer` or `const_buffer` should take any class
> that has a `.data()` and `.size()` member. This way `value_type` can fulfill
> the requirement of `ConvertibleToBuffer` without needing the dependency on a
> concrete type.

That is quite a good idea! But that would require a change to the
Networking-TS which means writing a paper. And it would have to be
changed in Asio as well, since we're modifying the meaning of a
concept.

> Another option, is just moving these concrete buffer classes from Asio to your
> new library...

Yes, that is the approach that I am taking with Boost.Buffers

>...and then Boost.Asio will depend on Boost.Buffers.

Of course that would be great, but I can't presume that the author
would be open to making that dependency. We also have to be mindful
that stand-alone Asio is the upstream library - Boost.Asio is
generated from stand-alone Asio via script. In order to make
Boost.Asio depend on Boost.Buffers some accomodation would need to be
made.

However, making Boost.Asio depend on Boost.Buffers is not strictly
necessary, I have a work-around that lets the user decide where to get
the header files from:
<https://github.com/vinniefalco/buffers/blob/30ef7031ec0909972a720c0cdd8d6c6e1cc9e37b/include/boost/buffers/asio.hpp#L13>

I plan on moving beast's dynamic buffer implementations and buffer
adapters into Boost.Buffers as well, I will describe this plan in a
new post shortly.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [beast] A Networking-TS version of Boost.Asio and Boost.Beast is here!

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Wed, Oct 4, 2017 at 7:51 AM, paul <[hidden email]> wrote:
> Ideally, the constructor to `buffer` or `const_buffer` should take any class
> that has a `.data()` and `.size()` member. This way `value_type` can fulfill
> the requirement of `ConvertibleToBuffer` without needing the dependency on a
> concrete type.

There's another solution that we spit-balled, it is this:

    using const_buffer = std::pair<void const*, std::size_t>;
    using mutable_buffer = std::pair<void*, std::size_t>;

Now ConvertibleToConstBuffer just means convertible to std::pair<void
const*, std::size_t> which is a plain std:: type. This also would
require a paper to change Networking-TS.

What do you think?

Thanks

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost