On 23 Aug 2015 at 15:05, Glen Fernandes wrote:
On Sun, Aug 23, 2015, Niall Douglas wrote:
Is acceptance of AFIO into Boost going to be judged on technical reasons, or politics, or "I don't understand the point of this library?"
Isn't "I don't understand the point of this library" a valid reason for rejection?
In itself, no I don't think so. There are at least ten libraries in Boost I have no understanding of the point of (mostly the Maths ones). They are beyond me. Last year I didn't understand the point of Edward's Boost.VMD library, and I still don't. But other people said they were using it and it was useful to them. That's plenty good enough for me. I think the same applies here. Most C++ programmers think they have zero need for race free file system [1]. So why bother with AFIO? Most C++ programmers have no need to do asynchronous filesystem or file i/o. So why bother with AFIO? Very few programmers anywhere in the world have a need for file i/o to follow POSIX atomicity guarantees so they can write lock free filesystem code. Probably only a few thousand in the world. Anyone not crazy would just take a lock file and make it easy on themselves. It's a niche library, no doubt. Just as Boost.VMD or Boost.uBLAS. There is a small minority who will see a need for using it at all. Everybody else will be, at best, indifferent. At worst, confused. [1]: There is definitely quite a bit of interest in race free filesystem at WG21. My talk on race free filesystem at CppCon looks like it will be well attended given who is also speaking in the same time slot.
This is where you may have compromised the review (in my opinion):
- The documentation isn't very straightforward. To me, it feels like it is all over the place
There is a lot of rare and hard to find documentation on real world filing system behaviour in there. It has taken me months to collate, some of which was from walking through operating system kernel code. It's absolutely invaluable to people writing code in this niche field, I already get quite a bit of email from people who found the information from google mostly with thanks and Paypal donations typically $25 or more. But from the perspective of a Boost library review, it's clutter and non-essential and distracting. I'm kinda caught here - is the documentation for Boost peer reviewers, or for the actual Boost library end user? I decided on the latter. Maybe I was wrong.
- The examples in the documentation (bar the first one) also aren't very straightforward
The very first one was STL iostreams, so no AFIO at all. Can you explain what is not straightforward more precisely please?
You have said some things which make people question whether they really even need AFIO: - On more than one occasion you claimed that nobody needs an asynchronous file I/O library (and synchronous I/O coupled with some concurrency facilities like threads are sufficient).
I think I said that I thought that nobody *here* needs AFIO. Most C++ programmers think that ostream << obj; is all you ever need, and they are probably right until they run into performance problems or start losing data.
- That one needs AFIO not for performance (which you've demonstrated that it doesn't offer) but for safety, reliability, etc. This alienates everyone who doesn't care about these things.
Most C++ programmers will never use std::atomic nor Boost.Atomic nor do they care about atomics. AFIO is essentially Boost.Atomic for the file system, right down to acquire, release and seq_cst. Does this analogy help? Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/