The formal review of the Boost.AFIO library starts, August 21st and ends on Monday August 31st. Boost.AFIO provides a portable API implementing synchronous and asynchronous race-free filesystem and scatter-gather file i/o. It requires a minimum of C++ 11. It has minimum dependencies on a Filesystem TS and a Networking TS implementation (e.g. Boost.Filesystem and Boost.ASIO). Backends are provided for the Windows NT kernel and POSIX. The utility of a portable library providing strong concurrent race guarantees about filesystem and file i/o can be seen in its tutorial where a transactional ACID key-value store is built from first principles. Boost.AFIO was brought to Boost as part of GSoC 2013 and Niall Douglas has continued to develop and improve the library since then, generating two internal implementation libraries Boost.APIBind and Boost.Monad which are expected to be separately brought for Boost review in 2016. The documentation can be found here: https://boostgsoc13.github.io/boost.afio/doc/html/afio.html The source code can be found here: https://github.com/BoostGSoC13/boost.afio/tree/boost-peer-review Online web compiler playpen can be found here: http://melpon.org/wandbox/permlink/DR8wCpu5Rl20GMdM? Please answer the following questions: 1. Should Boost.AFIO be accepted into Boost? Please state all conditions for acceptance explicity. 2. What is your evaluation of the design? 3. What is your evaluation of the implementation? 4. What is your evaluation of the documentation? 5. What is your evaluation of the potential usefulness of the library? 6. Did you try to use the library? With what compiler? Did you have any problems? 7. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? 8. Are you knowledgeable about the problem domain?
Le 23/08/15 03:08, Ahmed Charles a écrit :
The formal review of the Boost.AFIO library starts, August 21st and ends on Monday August 31st.
Boost.AFIO provides a portable API implementing synchronous and asynchronous race-free filesystem and scatter-gather file i/o. It requires a minimum of C++ 11. It has minimum dependencies on a Filesystem TS and a Networking TS implementation (e.g. Boost.Filesystem and Boost.ASIO). Backends are provided for the Windows NT kernel and POSIX.
The utility of a portable library providing strong concurrent race guarantees about filesystem and file i/o can be seen in its tutorial where a transactional ACID key-value store is built from first principles.
Boost.AFIO was brought to Boost as part of GSoC 2013 and Niall Douglas has continued to develop and improve the library since then, generating two internal implementation libraries Boost.APIBind and Boost.Monad which are expected to be separately brought for Boost review in 2016. Hi,
Niall, Ahmed, it will be very difficult to review this library as it has dependencies on libraries that are not adopted by Boost. The documentation is full of references to both libraries APBind and Monad. If they are internals, no mention should be done on the documentation. I will suggest also to move any references to the history of the library or the future of the libary to a specific section, the user just wants to know what AFIO can be used for now. Best, Vicente
Am 23. August 2015 18:13:52 MESZ, schrieb "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>:
Niall, Ahmed, it will be very difficult to review this library as it has dependencies on libraries that are not adopted by Boost. The documentation is full of references to both libraries APBind and Monad.
If they are internals, no mention should be done on the documentation.
AFAIK Monad is visible to the user as AFIO functions return them. Cheers -Andreas -- Sent from my mobile. No type gold.
From: Boost-users [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Ahmed Charles Sent: 23 August 2015 02:09 To: boost-announce@lists.boost.org; boost-users@lists.boost.org Subject: [Boost-users] [boost] [afio] Formal review of Boost.AFIO The formal review of the Boost.AFIO library starts, August 21st and ends on Monday August 31st. Boost.AFIO provides a portable API implementing synchronous and asynchronous race-free filesystem and scatter-gather file i/o. It requires a minimum of C++ 11. It has minimum dependencies on a Filesystem TS and a Networking TS implementation (e.g. Boost.Filesystem and Boost.ASIO). Backends are provided for the Windows NT kernel and POSIX. The utility of a portable library providing strong concurrent race guarantees about filesystem and file i/o can be seen in its tutorial where a transactional ACID key-value store is built from first principles. Boost.AFIO was brought to Boost as part of GSoC 2013 and Niall Douglas has continued to develop and improve the library since then, generating two internal implementation libraries Boost.APIBind and Boost.Monad which are expected to be separately brought for Boost review in 2016. The documentation can be found here: https://boostgsoc13.github.io/boost.afio/doc/html/afio.html The source code can be found here: https://github.com/BoostGSoC13/boost.afio/tree/boost-peer-review Online web compiler playpen can be found here: http://melpon.org/wandbox/permlink/DR8wCpu5Rl20GMdM? Please answer the following questions: 1. Should Boost.AFIO be accepted into Boost? Please state all conditions for acceptance explicity. Provisionally, yes. Requirements: . Major restructuring of documentation. (Not re-writing!) . Completion of Boost.Was_Called_Monad and APBind. . Creation of a TODO list. . Mini-review before going into a release (perhaps of all together?). . More documentation of examples to explain what they demonstrate. 2. What is your evaluation of the design? Not qualified to judge. 3. What is your evaluation of the implementation? Mature-ish but still evolving. Incomplete - but that is no reason for rejecting a library. Just as "No battle plan survives the first contact with the enemy". No software does either. IMO what we are deciding is if we want this software to be developed and maintained, not, as some mistakenly imagine, if it is finished and complete ready to go into the 1.60 release. It isn't and won't be until 1.61 at the very earliest, and will still be modified after release because . It is using cutting edge tools. . It is breaking new ground and will be changes by C++ Standard, Library and compiler changes. Personally, I don't believe that Incubator is the right way to speed development of this software. I think we need to alter the Boost review and acceptance process. I favour accepting this quite mature software and being prepared for it to change as a result of user experience. It won't get users until it is part of a release, as we are running things at present. I have a violent objection to the name monad - anywhere in Boost. As I have said before. It just seems unsuitable for the task - it's just far too general - you wouldn't have a function called 'sub-routine'? Better to called it "useful_software_thingy_but_we_don't_have_a_good_name_for_it_yet!" Names really do matter! 4. What is your evaluation of the documentation? Looks nice. Excellent index. Good documentation of functions. But impossible to see the wood for the trees! L (Ability to add comments makes it even worse at review time!) Get into far too many details far too soon. Feels like a stream-of-consciousness dump L Overall structure and sections need major re-thinking and re-structuring. (Getting someone not 'burdened by knowing too much' might be the best idea?) We don't need configuration info in the introduction, for example. I'd use Quickbook code snippets and a link to the full code, so avoiding clutter like which namespace to use. The full code should be user runnable and linked from the text. Move all the 'coming soon trailers' to a separate "Planned enhancements" or "Roadmap" section (and provide links to that where necessary in the text. I didn't find the callouts on the "Table 1.10. Traditional STL iostreams and AFIO side by side" at all helpful - why not just add C++ comments? For the time being, I'd prefer that the (very informative) papers on this immensely complex subject held elsewhere and referenced rather than being part of this documentation (at least while we are reviewing). (This is especially as it contains reference to a TripleGIT system which I suspect is conceptware at best and vapourware at worse). 5. What is your evaluation of the potential usefulness of the library? Niche at present, but what the library offers will undoubtedly be useful to far more people than they now realise, and far sooner. 6. Did you try to use the library? With what compiler? Did you have any problems? Worked out that I could not use this without VS2015 and I'm still in the dim ages of VS2013. 7. How much effort did you put into your evaluation? A quick reading. 8. Are you knowledgeable about the problem domain? No, but I expect to have to become so. Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
On 8/25/15 4:37 AM, Paul A. Bristow wrote:
Please answer the following questions:
1. Should Boost.AFIO be accepted into Boost? Please state all conditions for acceptance explicity.
Provisionally, yes.
Requirements: <snip>
This list of requirements constitutes much more than a "a few changes". It's impossible to know what what the library would like like after all these changes and and their repercussions were addressed. I don't think we can realistically expect the review manager to verify that and library with all these changes is sufficiently close the current one to take responsibility for signing off on the final version. To my mind, this would require a new review once all the changes are made. So the appropriate recommendation in this case would be to reject the library and encourage the author to consider all the feedback from the review and re-submit. Robert Ramey
On 25 Aug 2015 at 8:17, Robert Ramey wrote:
Please answer the following questions:
1. Should Boost.AFIO be accepted into Boost? Please state all conditions for acceptance explicity.
Provisionally, yes.
Requirements: <snip>
This list of requirements constitutes much more than a "a few changes". It's impossible to know what what the library would like like after all these changes and and their repercussions were addressed. I don't think we can realistically expect the review manager to verify that and library with all these changes is sufficiently close the current one to take responsibility for signing off on the final version.
I read the provisional yes as meaning yes to how the library is roadmapped to look like in the future, and he recommends an additional mini-review at that point which could introduce yet another mini-review after again. In other words, he's saying fundamentally it's good, but needs a lot more work yet. Paul please do correct me if I am wrong in this interpretation. There is precedent for this: Boost.Fiber was provisionally approved here as a C++ 98 library with condition of a mini-review before entry. Boost.Fiber is now a C++ 14 library and sufficiently different from the library originally reviewed it may require a second mini-review if during its first mini-review it is felt still lacking. I think this pattern of repeated mini-reviews caused by changes to the common implementations of the C++ standard rather than the libraries themselves is going to be very common next few years. All these changes to AFIO are almost entirely driven by changes since 2012 to the various WG21 technical standards. If they hadn't changed and C++ compilers (specifically MSVC) hadn't changed, AFIO wouldn't have changed. It's very similar for Fiber, which had to be refactored in the face of substantial changes in C++ 14. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On 8/25/15 10:28 AM, Niall Douglas wrote:
There is precedent for this: Boost.Fiber was provisionally approved here as a C++ 98 library with condition of a mini-review before entry. Boost.Fiber is now a C++ 14 library and sufficiently different from the library originally reviewed it may require a second mini-review if during its first mini-review it is felt still lacking.
This is a precedent - a bad one which I hope to avoid a repetition of in the future. A library which is accepted should be close enough to it's final state so that it can be finished up on the order of a couple of months and will result in a final version which is close to what reviewers actually reviewed. We can't have a library pass a review, then have the package morph into something significantly different then have it accepted. This make the original review a farce.
I think this pattern of repeated mini-reviews caused by changes to the common implementations of the C++ standard rather than the libraries themselves is going to be very common next few years.
LOL - maybe, but only if we let it. All
these changes to AFIO are almost entirely driven by changes since 2012 to the various WG21 technical standards. If they hadn't changed and C++ compilers (specifically MSVC) hadn't changed, AFIO wouldn't have changed.
It's very similar for Fiber, which had to be refactored in the face of substantial changes in C++ 14.
I seriously doubt that a package which compiles and passes tests and reviews with C++03 cannot do these things when C++11 comes out. What really happens is that the author sees opportunities with C++11 that he didn't have before then starts incorporating them after the original review. I guess this would be called feature creep or implementation creep. In any case, it indicates that the original acceptance was premature. Ultimately it hinges on what "acceptance into Boost" means. To me it's a library ready - with a few straight forward / uncontroversial changes which is ready to be incorporated into the boost distribution. It's not acceptance of an idea for a library, a prototype for a library, or that a developer is certified to add a library in the future. Robert Ramey
To me it's a library ready - with a few straight forward / uncontroversial changes which is ready to be incorporated into the boost distribution. It's not acceptance of an idea for a library, a prototype for a library, or that a developer is certified to add a library in the future.
I would trust that the review manager will treat any recommendation for acceptance that is driven mostly by a "This library has potential [after substantial development]" sentiment and not an "I would use this library today" sentiment accordingly. Glen -- View this message in context: http://boost.2283326.n4.nabble.com/boost-afio-Formal-review-of-Boost-AFIO-tp... Sent from the Boost - Users mailing list archive at Nabble.com.
On 8/25/15 4:37 AM, Paul A. Bristow wrote:
IMO what we are deciding is if we want this software to be developed and maintained, not, as some mistakenly imagine, if it is finished > and complete ready to go into the 1.60 release. It isn’t and won’t be until 1.61 at the very earliest, and will still be modified after > > release because
It is using cutting edge tools.
It is breaking new ground and will be changes by C++ Standard, Library and compiler changes.
Personally, I don’t believe that Incubator is the right way to speed development of this software.
Hmmm - why not?
I think we need to alter the Boost review and acceptance process.
In what way?
I favour accepting this quite mature software and being prepared for it to change as a result of user experience. It won’t get users until it is part of a release, as we are running things at present.
What is to be gained by this? Given the scope of the changes you've cited, it would have to be re-reviewed anyway. And aamini-review or re-review by the release manager would not be sufficiently exhaustive and would not draw enough people to repeat the process. Likely it would result in acceptence a library which hasn't really been scrutinized - which the outcome which I aspire to prevent. What does "accept" mean here. That we think it has promise but needs work? To me it means that this library is basically correct and with some straightforward changes will meet the boost user's expectations. There is no reason that a library which is not accepted cannot be developed further in order to meet Boost's requirements and be re-submitted. I know for a fact that this is true because that's what I did. Robert Ramey
-----Original Message----- From: Boost-users [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Robert Ramey Sent: 25 August 2015 20:20 To: boost-users@lists.boost.org Subject: Re: [Boost-users] [boost] [afio] Formal review of Boost.AFIO
On 8/25/15 4:37 AM, Paul A. Bristow wrote:
IMO what we are deciding is if we want this software to be developed > and maintained, not, as some mistakenly imagine, if it is finished > > and complete ready to go into the 1.60 release. It isn't and won't be > until 1.61 at the very earliest, and will still be modified after > > > release because
It is using cutting edge tools.
It is breaking new ground and will be changes by C++ Standard, Library and compiler changes.
Personally, I don't believe that Incubator is the right way to speed > development of this software.
Hmmm - why not?
I think it will never take off until 'official'. That is most unreasonable, but a fact of life.
I think we need to alter the Boost review and acceptance process.
In what way?
Having two 'status' flags: * mature and 'standard' - stable and bug-free (we hope). * 'experimental' - usable but still be being improved. The C++ Standards people have started to accept the need for 'experimental' status. (Of course, the 'status' is really a continuum, not a bool). My main reason is that I believe that people won't use libraries until they are in the release. And without lots of users ("first encounter with the enemy") , you don't find if things are really useful or not. IMO, too many Boost reviews are by far too few people and with too little real-life use. Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
Paul wrote:
I think it will never take off until 'official'. That is most unreasonable, but a fact of life.
I was under the impression that the Incubator was official (or at least officially endorsed, just not mandated as part of the review process). Glen -- View this message in context: http://boost.2283326.n4.nabble.com/boost-afio-Formal-review-of-Boost-AFIO-tp... Sent from the Boost - Users mailing list archive at Nabble.com.
I'm an avid user of Boost, and this is the first I've heard of the Incubator. If you want people to use it, you need to make it clearly accessible from the Boost.org website. I suspect that I am not alone in that I never thought to look for an incubator for Boost. The only experimental Boost software I'm currently using is some lat/lon experimental code for Boost.Geometry. And I only know about that because I stumbled onto it. I would probably use more experimental code (like Boost.DLL) if I knew how to access it. Keep in mind that the vast majority of Boost users, while they appreciate the quality of the libraries, probably have no clue about the approval process. So they may not think to look for things that aren't easily accessible from the Boost.org website. I understand the desire to uphold the high standards to which Boost has heretofore subscribed - and I agree with that. I also agree that 'given enough eyes, all bugs are shallow'. Any mechanism that can easily increase the number of effective eyeballs while maintaining high quality standards should be considered. --- Steve H. -----Original Message----- From: Glen Fernandes [mailto:glen.fernandes@gmail.com] Sent: Wednesday, August 26, 2015 5:18 AM To: boost-users@lists.boost.org Subject: Re: [Boost-users] [boost] [afio] Formal review of Boost.AFIO Paul wrote:
I think it will never take off until 'official'. That is most unreasonable, but a fact of life.
I was under the impression that the Incubator was official (or at least officially endorsed, just not mandated as part of the review process). Glen -- View this message in context: http://boost.2283326.n4.nabble.com/boost-afio-Formal-review-of-Boost-AFIO-tp... Sent from the Boost - Users mailing list archive at Nabble.com.
Paul wrote:
I think it will never take off until 'official'. That is most unreasonable, but a fact of life.
I was under the impression that the Incubator was official (or at least officially endorsed, just not mandated as part of the review process).
If its officially endorsed, then there should be a link to it on boost.org. There is still a link to the no longer used sandbox. The sandbox should ultimately be replaced by the incubator. Paul -- View this message in context: http://boost.2283326.n4.nabble.com/boost-afio-Formal-review-of-Boost-AFIO-tp... Sent from the Boost - Users mailing list archive at Nabble.com.
The announcement that gave me the impression that it was endorsed was: http://lists.boost.org/boost-announce/2014/06/0409.php Paul F. II wrote:
If its officially endorsed, then there should be a link to it on boost.org. There is still a link to the no longer used sandbox. The sandbox should ultimately be replaced by the incubator.
I agree. Glen -- View this message in context: http://boost.2283326.n4.nabble.com/boost-afio-Formal-review-of-Boost-AFIO-tp... Sent from the Boost - Users mailing list archive at Nabble.com.
On 8/26/15 4:11 AM, Paul A. Bristow wrote:
-----Original Message----- From: Boost-users [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Robert Ramey Sent: 25 August 2015 20:20 To: boost-users@lists.boost.org Subject: Re: [Boost-users] [boost] [afio] Formal review of Boost.AFIO
On 8/25/15 4:37 AM, Paul A. Bristow wrote:
Personally, I don't believe that Incubator is the right way to speed > development of this software.
Hmmm - why not?
I think it will never take off until 'official'. That is most unreasonable, but a fact of life.
I'm not convinced of this. I think that if something works well and serves a real need, people will use it and it will eventually be "co-opted" by "official" institutions. If this isn't happening with the incubator - it's because it isn't deemed useful enough - at least for it's original intended purpose. The only real purpose of the "official" institutions is to give the impression that the process is more orderly than it actually is. The incubator get's around 1000 vists / month. It's also surprisingly easy to maintain - requires hardly any time to keep it running. So I'm dis-inclined to write it off entirely. Making improvements does consume a lot of time unfortunately. So my point of view would be that the incubator needs to evolve or perhaps change it's stated goal. At that time it was conceived, a huge concern was the lack of persons willing to be review managers. Lately this concern has been less in the news. I'm not sure why that is, maybe it's a coincidence or maybe it has worked in some way that I don't understand. My original vision was that it would avoid the situation where a library author thinks he's done and submits a library and it's really not. So that a huge amount of effort is wasted by library author and reviewers. Lately it seems we have more reviewers also so this situation seem quite so urgent. Another thing I was that I wanted to preserve the history and commentary on libraries in a convenient way. To me, a boost library is much more than a bunch of C++ code. The documentation, discussion, etc. is an essential part of the package. I feel that much valuable information on libraries such as rationale for design decisions, reasons for rejection, etc. .. is "lost". Technically it might not be lost - but it's hard to dig up on a convenient manner. So I invested effort in a system for comments/reviews with comments etc modeled on the developer's list. I've been disappointed that this hasn't taken hold. This aspect needs some new ideas which haven't occurred to me yet.
I think we need to alter the Boost review and acceptance process.
In what way?
Having two 'status' flags:
* mature and 'standard' - stable and bug-free (we hope). * 'experimental' - usable but still be being improved.
The C++ Standards people have started to accept the need for 'experimental' status.
(Of course, the 'status' is really a continuum, not a bool).
Bottom line, I think Boost works because it limits it scope to some relatively simple rules and passes judgement whether or not various initiatives meet those rules. It doesn't really DO anything other than that. In line with this - I think the review process should continue to confine itself mostly passing judgement on submissions and limit it's active design/intervention/management/promotion of the library development itself.
My main reason is that I believe that people won't use libraries until they are in the release.
That's because people have come to depend on the boost "brand" as sign of quality. Diluting this brand by "accepting conditionally" or otherwise promoting libraries which don't meet our standards for quality and completeness will be counter productiive.
And without lots of users ("first encounter with the enemy") , you don't find if things are really useful or not.
IMO, too many Boost reviews are by far too few people and with too little real-life use.
Ahhh - on this we agree. I would hope that we could more people to use libraries which have been submitted before they are actually reviewed and that these people could be encouraged to make reviews. I think that the major obstacle is that most libraries that the authors think are good are just not good enough. Most authors underestimate the requirements of the "customers" and think that "good code" is enough. (Besides over-estimating the quality of their code). I did make a presentation on this subject at Boost Con 2014. https://www.youtube.com/watch?v=ACeNgqBKL7E Attendance was an underwhelming 14 attendees. LOL - my life is filled with disappointments. Robert Ramey
I have reviews from the following people: Roland Bock <rbock@eudoxos.de> Paul A. Bristow <pbristow@hetp.u-net.com> Thomas Heller <thom.heller@gmail.com> Hartmut Kaiser <hartmut.kaiser@gmail.com> Jeremy Maitin-Shepard <jeremy@jeremyms.com> If you've sent a review and I've missed it, do let me know. There have been lots of emails this week and I want to make sure I've caught all of the reviews. On 8/22/2015 6:08 PM, Ahmed Charles wrote:
The formal review of the Boost.AFIO library starts, August 21st and ends on Monday August 31st.
Boost.AFIO provides a portable API implementing synchronous and asynchronous race-free filesystem and scatter-gather file i/o. It requires a minimum of C++ 11. It has minimum dependencies on a Filesystem TS and a Networking TS implementation (e.g. Boost.Filesystem and Boost.ASIO). Backends are provided for the Windows NT kernel and POSIX.
The utility of a portable library providing strong concurrent race guarantees about filesystem and file i/o can be seen in its tutorial where a transactional ACID key-value store is built from first principles.
Boost.AFIO was brought to Boost as part of GSoC 2013 and Niall Douglas has continued to develop and improve the library since then, generating two internal implementation libraries Boost.APIBind and Boost.Monad which are expected to be separately brought for Boost review in 2016.
The documentation can be found here: https://boostgsoc13.github.io/boost.afio/doc/html/afio.html
The source code can be found here: https://github.com/BoostGSoC13/boost.afio/tree/boost-peer-review
Online web compiler playpen can be found here: http://melpon.org/wandbox/permlink/DR8wCpu5Rl20GMdM?
Please answer the following questions:
1. Should Boost.AFIO be accepted into Boost? Please state all conditions for acceptance explicity. 2. What is your evaluation of the design? 3. What is your evaluation of the implementation? 4. What is your evaluation of the documentation? 5. What is your evaluation of the potential usefulness of the library? 6. Did you try to use the library? With what compiler? Did you have any problems? 7. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? 8. Are you knowledgeable about the problem domain?
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-announce
Ahmed wrote:
I have reviews from the following people: - Roland Bock - Paul A. Bristow - Thomas Heller - Hartmut Kaiser - Jeremy Maitin-Shepard
There is also a review from: - Andreas Schäfer Glen -- View this message in context: http://boost.2283326.n4.nabble.com/boost-afio-Formal-review-of-Boost-AFIO-tp... Sent from the Boost - Users mailing list archive at Nabble.com.
I have received/noted these additional reviews: Andreas Schafer <gentryx@gmx.de> Antony Polukhin <antoshkka@gmail.com> Giovanni Piero Deretta <gpderetta@gmail.com> If you are still working on a review that you would like to be considered, let me know. Otherwise, I'll be summarizing the results in a future mail. On 8/31/2015 1:13 AM, Ahmed Charles wrote:
I have reviews from the following people:
Roland Bock <rbock@eudoxos.de> Paul A. Bristow <pbristow@hetp.u-net.com> Thomas Heller <thom.heller@gmail.com> Hartmut Kaiser <hartmut.kaiser@gmail.com> Jeremy Maitin-Shepard <jeremy@jeremyms.com>
If you've sent a review and I've missed it, do let me know. There have been lots of emails this week and I want to make sure I've caught all of the reviews.
On 8/22/2015 6:08 PM, Ahmed Charles wrote:
The formal review of the Boost.AFIO library starts, August 21st and ends on Monday August 31st.
Boost.AFIO provides a portable API implementing synchronous and asynchronous race-free filesystem and scatter-gather file i/o. It requires a minimum of C++ 11. It has minimum dependencies on a Filesystem TS and a Networking TS implementation (e.g. Boost.Filesystem and Boost.ASIO). Backends are provided for the Windows NT kernel and POSIX.
The utility of a portable library providing strong concurrent race guarantees about filesystem and file i/o can be seen in its tutorial where a transactional ACID key-value store is built from first principles.
Boost.AFIO was brought to Boost as part of GSoC 2013 and Niall Douglas has continued to develop and improve the library since then, generating two internal implementation libraries Boost.APIBind and Boost.Monad which are expected to be separately brought for Boost review in 2016.
The documentation can be found here: https://boostgsoc13.github.io/boost.afio/doc/html/afio.html
The source code can be found here: https://github.com/BoostGSoC13/boost.afio/tree/boost-peer-review
Online web compiler playpen can be found here: http://melpon.org/wandbox/permlink/DR8wCpu5Rl20GMdM?
Please answer the following questions:
1. Should Boost.AFIO be accepted into Boost? Please state all conditions for acceptance explicity. 2. What is your evaluation of the design? 3. What is your evaluation of the implementation? 4. What is your evaluation of the documentation? 5. What is your evaluation of the potential usefulness of the library? 6. Did you try to use the library? With what compiler? Did you have any problems? 7. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? 8. Are you knowledgeable about the problem domain?
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-announce
participants (2)
-
Ahmed Charles -
gentryx＠gmx.de -
Glen Fernandes -
Hickman, Steve (AdvTech) -
Niall Douglas -
Paul A. Bristow -
Paul Fultz II -
Robert Ramey -
Vicente J. Botet Escriba