Re: [boost] Two mqtt libraries

On Mon, May 20, 2024 at 10:06 PM Robert Ramey via Boost 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 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