Boost logo

Boost :

From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2023-12-03 18:11:55


pt., 1 gru 2023 o 18:42 Vinnie Falco <vinnie.falco_at_[hidden]> napisał(a):

> On Fri, Dec 1, 2023 at 8:25 AM Andrzej Krzemienski via Boost
> <boost_at_[hidden]> wrote:
> > My impression is that it is not popular, surely far less than the HTTP
> protocol.
>
> Nothing is going to come close to the popularity of HTTP but this MQTT
> is a super-annoying protocol which unfortunately has a dedicated niche
> for which the use-case is ideal. People invent their own MQTT
> libraries almost as often as they write their own JSON libraries.
>
> > My question to the Boost community is, does every good library need to
> be included in Boost?
>
> In general, I would say no.
>
> > I thought that Boost was supposed to be an "extended Standard Library",
> containing:
> >
> > 1. Portability fixes
> > 2. Implementing missing language features
> > 3. Vocabulary types (I consider Boost.ASIO one)
> > 4. Frequently used components
> > 5. Ground-breaking designs and ideas
> >
> > Async.MQTT5 doesn't fit into any of these categories. (Neither does
> Boost.AEDIS or Boost.MySql.)
>
> I agree that Aedis, MySQL, and MQTT5 do not precisely fit your list
> above. However, there is a certain synergy with Asio, Beast, Aedis,
> MySQL, and the proposed MQTT which has merit. The reality is that
> users are increasingly turning away from Boost in favor of the
> standard library (this is a conversation for another thread). If Boost
> only limits itself to items one through four in your list above, the
> value proposition for Boost becomes unclear over time.
>

Boost used to be a testing and experimentation ground before LWG. Are you
saying LWG doesn't need new libraries? Or that the community doesn't need
standard-library-like libraries?

>
> One of the ways we might envision Boost reinventing itself is to
> capitalize on the one area where Boost is so far ahead that there is
> simply no competition:
>
> "The C++ standard can't even connect to the Internet." - Vinnie Falco
>

"Reinventing"? It sounds like "we are a group of people, one adventure
ended, let's look for a new one". Is that what you mean?

> Based on the papers coming out of wg21 I suspect that
> committee-designed networking and its accompanying replacement for
> Kohlhoff's executors are going to be at the same level of quality and
> usability as, say, ranges. Make of that what you will.
>
> In the meanwhile if we can position Boost to have a strong set of
> networking libraries that work together well

So, are Beast, AEDIS, MySql and now this MQTT5 working well together? Do
they use similar structure, naming conventions and the design?

this gives us a unique
> advantage.

Advantage over what?

Regards,
&rzej;

People will grudgingly download Boost despite the usual
> irrational complaints ("too big", "too many dependencies",
> "inconsistent quality") because they cannot get this set of harmonious
> features anywhere else.
>
> There is a group of authors and contributors working on a technology
> demo which integrates all of the networking libraries in Boost into
> several applications to showcase how the libraries might be used
> together to build enterprise-ready systems. This project is called
> "Boost ServerTech" and you can learn more about it here:
>
> BoostServerTech project proposal
>
> https://docs.google.com/document/d/1ZQrod1crs8EaNLLqSYIRMacwR3Rv0hC5l-gfL-jOp2M/edit
>
> Architecture Documentation
> https://anarthal.github.io/servertech-chat/01-architecture.html
>
> Boost ServerTech Chat
> https://github.com/anarthal/servertech-chat
>
> Ruben Perez is a C++ Alliance Staff Engineer who is spearheading this
> project.
>
> >
> > Do we have a clear set of criteria for what belongs to Boost? And I do
> not
> > mean only the quality bar, but also the range of business domain.
> > What's wrong with a good library hosted on its own in GitHub?
>
> There is not a clear set of criteria, but I think that our Contributor
> Guide should offer some kind of guidance on "what belongs in Boost." A
> rigid set of rules doesn't really make sense for me. Since libraries
> are quite unique as well as their authors, we should evaluate each
> library on a case by case basis, with some general principles posted
> in the documentation so that newcomers to the mailing list can orient
> themselves.
>
> Thanks
>


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk