Re: Two mqtt libraries

From: Klemens Morgenstern (klemensdavidmorgenstern_at_[hidden])
Date: 2024-05-20 15:13:38

On Mon, May 20, 2024 at 10:06 PM Robert Ramey via Boost
<boost_at_[hidden]> wrote:
>
> On 5/20/24 1:20 AM, Klemens Morgenstern via Boost wrote:
> > On Sun, May 19, 2024 at 2:27 AM Robert Ramey via Boost
> > <boost_at_[hidden]> wrote:
> >>
> >> I've been contacted by my friend and sometime collaborator Takatoshi
> >> Kondo regarding his submission of a boost library:
> >> https://github.com/redboltz/async_mqtt. It has received two
> >> endorsements. He has asked me to be review manager and I'm inclined to
> >> accept this request as he was very helpful to me during the refinement
> >> of the boost serialization library.
> >>
> >> There is also mqtt client library that is proposed to the Boost.
> >> https://github.com/mireo/async-mqtt5 It also has endorsements and a
> >> review manager.
> >
> > I've been approached by the mireo authors and have volunteered to be
> > their review manager.
> >
> >
> >>
> >> A cursory examination of the git hub pages suggest considerable overlap
> >> between the two submissions.  In general, boost has discouraged the
> >> acceptance of multiple libraries with this much overlap - and for good
> >> reason.  An accepted library often becomes the canonical implementation
> >> in large parts of the C++ world.  Having two high quality libraries that
> >> do almost the same thing is not where we would like to be.
> >
> > Who's deciding "too much overlap"? Shouldn't this be up to reviewers?
>
> I don't think I said "too much overlap". It's true that I made only the
> most casual review of the two github sites.
>
> > In this case, mireo aims to be a safe & easy-to-use client library,
> > while redboltz is a protocol library that can also be used to build
> > servers.
>
> So... is my impression that these libraries overlap correct or
> incorrect?  My concern is that this would create a conflict.  Am I wrong
> about this?  If they really do address different domains and could
> coexist within boost, perhaps only a name change is called for.  Feel
> free to enlighten me on this.
>

They do overlap substantially, but not a 100%. It's borderline I'd say.

> >> I would like to propose that we review both libraries simultaneously in
> >> order to try to reach a consensus as to which, if either we want to
> >> accept.  I know this is a difficult task, but I think it is important
> >> that we do this.  It's going to be tough to reject a well written
> >> library because a better one has been accepted.  But it would be worse
> >> to reject a well written library merely because another one was
> >> submitted first.  Normally I don't participate as a review manager as
> >> I'm pretty bogged down in Boost stuff as it is.  But I'm willing to make
> >> an exception in this case due to the importance of this case and my
> >> strong personal ties to Takatoshi.  BTW - who is the review wizard these
> >> days?  I presume that he will be the one making the decision about this.
> >>
> >
> > What I would propose is that both libraries are review simultaneously
> > or back-to-back, but considered separate reviews.
>
> This could lead to the acceptance of both libraries.  Would that be a
> problem?  If so, how would it be resolved?
>

Well I personally would not consider that a problem if that's the
result of the review.

> > A few thoughts:
> >
> >   - The review manager exchange notes and publish their decision at the
> > same time.
> >   - Yet, these are two different reviews.
> >   - Reviewers are encouraged (yet not forced) to review both libraries.
> >   - The RM of library B can take into account if a reviewer only
> > reviews library A
> >   - The RM can also take into account the result of the other review
> > (e.g. if it's a close call for A, but B is accepted overwhelmingly)
> >
> >   - If we do the reviews simultaneously, do we need an extended period?
> >   - Can the RM of A write a review or participate in the discussion for B?
>
> I'm not sure what the boost review policy on this. I seem to recall the
> review manager participating in the discussion mostly to clarify
> misunderstandings.
>
> >   - Should consensus between RMs be required? Or could both libraries
> > be accepted?
>
> That's the question!!!
>
> I think we're on the same page as having simutaneous reviews.  I would
> argue that the outcome should be one decision by one person.  Since it
> seems that you've volunteered to review both libraries, you'd be the
> logical person to be the review manager.  Thanks for volunteering.  I
> don't envy you the task.
>

I only volunteered for the mireo library (i.e. the "other" one from
your perspective).
I don't think redboltz is ready for review so I don't want to be RM.
Furthermore I fear I might be too biased between the two of the
libraries to be review manager of both.

> Given that your much more knowledgable about the domain, I'd be curious
> on your opinion as two whether having both libraries in boost would be a
> good idea.
>

Well, I think in the case of mqtt having a pure protocol library isn't
as useful (as opposed to something as common as http).
I also think mireo's mqtt client library has a much higher acceptance
chance during review.

Additionally I don't know if there's a lot of interest in an mqtt
server library, but if there is, maybe it's worth exploring and
turning redboltz into a server & protocol library.
But that would require other people to endorse it. I am just convinced
that an mqtt client would be incredibly useful for lots of IoT
applications.

> I would also like to mention that I think this kind of library is
> suitable for Boost.  I don't expect to see this in the standard and it
> seems there is need for it.  So boost might be the logical home for it.
>
That's why I endorsed redboltz library.
I think having an asio-based mqtt library in boost makes perfect sense
as I consider boost a good home for any asio-based lib since the
networking TS was terminated.

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