On 22 Aug 2015 at 19:43, Glen Fernandes wrote:
Hartmut makes a good point. Niall, please correct me if my understanding is lacking here: - You are presenting this library with interface version A - You plan to implement interface version B while also providing A for backward compatibility - Once B is implemented, all documentation will only ever mention B because it is superior - The benefits of B make it superior in every way to A
Your understanding is lacking. v1.3 AFIO is the old, very well tested, mature engine with the original API from GSoC 2013. It is reliable, won't lose you data, exposes the POSIX race freedom guarantees, and is a good solid base for any file system application. It is not particularly friendly to program with, or at least that's what everyone has told me. v1.4 AFIO is the library being presented here. It has a new, much more friendly API which should address all the usability concerns people have expressed over the past two years. The *internal* *implementation* of the v1.4 AFIO you are being presented with is currently implemented internally using the v1.3 engine. That makes it just as reliable, just as well tested, just as solid a base for a database application as v1.3 AFIO is, except it is now easier to program against. A later *internal* implementation will be completely new, but that isn't important to this review because little external changes. Code written now still works later, just faster. Every Boost library sees substantial internal refactoring over time, AFIO is no different. Check out the tutorial yourself. If you think the API presented looks well designed and easy to use, if all the unit tests pass and have good coverage, if you think the documentation is up to scratch, if you feel the error handling is well implemented then vote for acceptance, with the condition I must return for an additional mini-review later if you like. If you feel the design of the API is fundamentally flawed, the unit tests are useless, the documentation rubbish, then vote for rejection.
The library being presented today is very well tested, and should *not* *lose* *you* *data* which is the most important quality in an i/o library. Even if performance - as you will see in the tutorial's benchmarks - is a bit poor in the current engine in some use cases.
I'm interested in an asynchronous file I/O library being part of Boost for performance (portably). As long as it is no less reliable than using the native filesystem APIs, reliability isn't a concern or a big selling point for me.
As the documentation lists out in great detail, and including a table of race guarantees per API in the reference docs and a table of what guarantees are available on each well known filing system, the reliability and sequential consistency guarantees offered by AFIO far exceed those of Filesystem or STL iostreams. Again, instead of jumping to conclusions based on ranting by a person with a well known personal vendetta against me, I'd suggest go read the documentation. If you come away with questions and concerns, ask them here. If you come away impressed, and I think you will be, all the better. If you come away thinking this library is deeply flawed and needs a substantial design refactoring, I am all ears because I would really love to know what's wrong with the AFIO API design *now* not later. That's why I am here, for a review of AFIO's design by my peers.
Am I to understand that by design, AFIO's implementation implies lower performance than an alternative? (even if that alternative is something like libuv, which has its own flaws)
Current performance benchmarks can be found throughout the documentation, specifically the tutorials, the release notes and the reference documentation. Is it lower performance than alternatives? Almost certainly, and the documentation takes pains to present AFIO in a worst possible light in any comparative benchmarks presented so nobody is under any illusions. What matters is correctness, reliability, reusability and portability - and most importantly of all - do NOT lose other people's data. As the tutorial shows, AFIO makes writing portable race free ACID safe file system code far easier than before, and there is your win case. And for reference, AFIO v1.3's internal dispatch engine is over 20x faster than v1.0 was. I am always working on internal implementation performance improvements as I identify problems and I figure out solutions, same as any other Boost library author here. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/