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. 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. 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. Robert Ramey
On Sun, May 19, 2024 at 2:27 AM Robert Ramey via Boost <boost@lists.boost.org> 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? 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.
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. 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? - Should consensus between RMs be required? Or could both libraries be accepted?
Robert Ramey
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
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@lists.boost.org> 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.
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?
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. 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. 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.
Robert Ramey
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Mon, May 20, 2024 at 10:06 PM Robert Ramey via Boost <boost@lists.boost.org> 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@lists.boost.org> 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
Hi, Regarding the overlap: I don't think it would be a problem. This is already in boost. Statemachine and MSM. Serialization and JSON. Statemachine and MSM both serve the exact same purpose. Serialization and JSON are not the same but I can use JSON to serialize my stuff with the from/to struct helper (don't remember the exact name right now) Bye Georg
On Sat, May 18, 2024 at 11:27 AM Robert Ramey via Boost < boost@lists.boost.org> wrote:
...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.
I have similar thoughts as you and until this year I had my own ideas about "what belongs in Boost." As there is no formal document or informal exposition offered by the Boost Libraries project website I evolved my own thinking as I am sure that others have done. However, upon discussions with high reputable sources (basically Peter Dimov), the criteria for "what belongs in Boost" is that "a library is useful." Applying this metric, I would think that if both MQTT libraries are useful then they should both be reviewed with the potential for acceptance. It really would be nice if there was some kind of documented rationale for what libraries belong in Boost as this would eliminate the speculation and guesswork. Thanks
On 5/20/24 8:28 AM, Vinnie Falco via Boost wrote:
On Sat, May 18, 2024 at 11:27 AM Robert Ramey via Boost < boost@lists.boost.org> wrote:
I have similar thoughts as you and until this year I had my own ideas about "what belongs in Boost." As there is no formal document or informal exposition offered by the Boost Libraries project website I evolved my own thinking as I am sure that others have done.
However, upon discussions with high reputable sources (basically Peter Dimov), the criteria for "what belongs in Boost" is that "a library is useful." Applying this metric, I would think that if both MQTT libraries are useful then they should both be reviewed with the potential for acceptance.
Since C++11 C++ standard committee accepted a large number of Boost libraries - thus fulfilling the original purpose of boost. The question then arose - what should Boost do now? Most successful organizations confront this problem. No one who has invested significant effort in the original organization wants to just wind it down. So the search for a new purpose is undertaken. In many cases, no such new purpose is found and the organization just withers into irrelevancy (even though as an organization it could linger on forever - at least until the money runs out). If it's a for profit organization, it's just killed off by lack of investors and customers. This is one of the signature benefits of Capitalism. Boost has been flailing around since that time looking for a new mission. I'd suggest a mission statement like: "The purpose of Boost is to encourage the development of useful quality C++ software not expected to be part of the C++ standard." I think much of the current infrastructure we have - review process etc. is well suited to the above stated purpose. I have a number of reservations about our development support aspects - website, build, documentation, etc. etc. which I've stated previously.
It really would be nice if there was some kind of documented rationale for what libraries belong in Boost as this would eliminate the speculation and guesswork.
Thanks
You're welcome. Robert Ramey
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Robert Ramey wrote:
I'd suggest a mission statement like:
"The purpose of Boost is to encourage the development of useful quality C++ software not expected to be part of the C++ standard."
A lot of what I've been doing _can_ be standardized, even if most of it probably won't be. E.g. https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2024/p3171r0.html So I don't think we need to restrict Boost to things that aren't going to ever be standard.
On 5/20/24 11:24 AM, Peter Dimov via Boost wrote:
Robert Ramey wrote:
I'd suggest a mission statement like:
"The purpose of Boost is to encourage the development of useful quality C++ software not expected to be part of the C++ standard."
A lot of what I've been doing _can_ be standardized, even if most of it probably won't be.
E.g. https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2024/p3171r0.html
So I don't think we need to restrict Boost to things that aren't going to ever be standard.
The closest I can find to a "Mission Statement" for Boost is on this page: https://www.boost.org "We emphasize libraries that work well with the C++ Standard Library. Boost libraries are intended to be widely useful, and usable across a broad spectrum of applications. The Boost license encourages the use of Boost libraries for all users with minimal restrictions. We aim to establish "existing practice" and provide reference implementations so that Boost libraries are suitable for eventual standardization. Beginning with the ten Boost Libraries included in the Library Technical Report (TR1) and continuing with every release of the ISO standard for C++ since 2011, the C++ Standards Committee has continued to rely on Boost as a valuable source for additions to the Standard C++ Library." Which strongly suggests a strong focus on enhancements to the standard library. It's also way too wordy for a "Mission Statement". I think rewording this and have a discussion thereof would be helpful us find our bearings again. I've made my suggestion above, what would be yours? Robert Ramey
No dia 20 de mai. de 2024, às 20:24, Peter Dimov via Boost <boost@lists.boost.org> escreveu:
Robert Ramey wrote:
I'd suggest a mission statement like:
"The purpose of Boost is to encourage the development of useful quality C++ software not expected to be part of the C++ standard."
A lot of what I've been doing _can_ be standardized, even if most of it probably won't be.
E.g. https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2024/p3171r0.html
So I don't think we need to restrict Boost to things that aren't going to ever be standard.
FWIW, I expect to release this week a research/opinion article on these very issues of standardization, WG21 and Boost. Joaquín M López Muñoz
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.
Has Mireo agreed to license their library under the BSL? I asked on Slack a few weeks ago, but the repo is still showing only BSD-3-Clause. Matt
Yes, we'll change the library license to BSL after the review. We originally chose the BSD 3-Clause license to avoid giving the impression that the library was already part of Boost.
On 21.05.2024., at 10:25, Matt Borland via Boost <boost@lists.boost.org> wrote:
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.
Has Mireo agreed to license their library under the BSL? I asked on Slack a few weeks ago, but the repo is still showing only BSD-3-Clause.
Matt<publickey - matt@mattborland.com - 0xC1382EAD.asc> _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Ivica
Ivica Siladic wrote:
Yes, we'll change the library license to BSL after the review.
You need to change it before any review. We don't want to be in a position where the future licence depends on the outcome of the review.
We originally chose the BSD 3-Clause license to avoid giving the impression that the library was already part of Boost.
There is plenty of non-Boost code out there using the Boost licence - in the same way that there is plenty of non-BSD code using the BSD licence. Regards, Phil.
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.
Hmm, a review manager admitting a strong bias for a potential library isn't a good look. To the point though, we should accept the protocol library one so it can be used for other networking implementations. Modern advancements can make implementations roughly 2x as fast as Asio. - Christian
On Tue, May 21, 2024 at 10:26 PM Christian Mazakas via Boost <boost@lists.boost.org> wrote:
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.
Hmm, a review manager admitting a strong bias for a potential library isn't a good look.
Where did I use the word "strong" exactly? It's just a more complex decision that means it's harder to know and then purposely ignore one's own bias, because it's a single variable. With two libraries you end up with a more complex situation where the way you present the libraries or schedule the reviews might advantage one over the other. And that can be subconscious, e.g. when announcing the review I might put some emphasis on a certain feature or deficiency of one library might influence reviewers a certain way. That's hard to account for, whereas a review decision that disagrees with my own opinion is pretty easy to reach and I have in the past. But I don't think it's a good idea to have a single review manager for two libraries in a competitive review with unclear rules. Maybe one of the review wizards and provide some wisdom on how this might work?
To the point though, we should accept the protocol library one so it can be used for other networking implementations. Modern advancements can make implementations roughly 2x as fast as Asio.
Well redboltz isn't a pure protocol library in that sense either, it's just lower level than mireos. It's still very much married to asio. It's akin to beast being on the protocol level, while a library like python-requests is a simpler client. To the point though, "we should accept" is not a thing to be discussed while scheduling a review, but during review.
- Christian
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Tue, May 21, 2024 at 7:26 AM Christian Mazakas via Boost < boost@lists.boost.org> wrote:
we should accept the protocol library one
Neither of the two proposed libraries are "sans-io." That is, they both contain algorithms which invoke Boost.Asio in their implementations. Thanks
participants (10)
-
Christian Mazakas -
Georg Gast -
Ivica Siladic -
Joaquín M López Muñoz -
Klemens Morgenstern -
Matt Borland -
Peter Dimov -
Phil Endecott -
Robert Ramey -
Vinnie Falco