Hello all, As part of cleaning up asio's interface I am pondering the utility of the read_at_least_n/write_at_least_n free functions. I'd appreciate hearing from anyone who actually uses these functions (or their async counterparts), and anyone else who has an opinion on the matter :) The rationale for their existence is the use case where you want to ensure that a minimum number of bytes are transferred, but are willing to receive more than that minimum in order to minimise the number of system calls. However I have never used them in practice, and suspect that an application that needed that level of control might prefer to use the lower level (i.e. partial-read/write) functions directly. I'm considering taking them out for now on the following basis: - I want to simplify the asio interface to improve clarity and ease-of-use. - I want to get asio ready for review asap. Including the functionality requires much more thought on how to make it elegant. - asio is obviously useful without them. So essentially I am proposing that the version of asio submitted for boost review does not include this functionality. If a compelling use case emerges in practice then the functionality can be added back after more careful consideration of the design (and with, I believe, no impact on other functionality). If somebody has a need right now, then I'll look at keeping them in, but it will delay getting a version ready for review submission. Cheers, Chris
On Fri, 11 Nov 2005 14:18:09 +1100 (EST), Christopher Kohlhoff wrote
Hello all,
As part of cleaning up asio's interface I am pondering the utility of the read_at_least_n/write_at_least_n free functions. I'd appreciate hearing from anyone who actually uses these functions (or their async counterparts), and anyone else who has an opinion on the matter :)
The rationale for their existence is the use case where you want to ensure that a minimum number of bytes are transferred, but are willing to receive more than that minimum in order to minimise the number of system calls. However I have never used them in practice, and suspect that an application that needed that level of control might prefer to use the lower level (i.e. partial-read/write) functions directly.
I'm considering taking them out for now on the following basis:
- I want to simplify the asio interface to improve clarity and ease-of-use.
- I want to get asio ready for review asap. Including the functionality requires much more thought on how to make it elegant.
- asio is obviously useful without them.
So essentially I am proposing that the version of asio submitted for boost review does not include this functionality. If a compelling use case emerges in practice then the functionality can be added back after more careful consideration of the design (and with, I believe, no impact on other functionality). If somebody has a need right now, then I'll look at keeping them in, but it will delay getting a version ready for review submission.
The comment isn't based on experience with asio interface, but on general design experience. I'd take them out. Your logic is good -- simplier is better, removing interfaces is difficult, adding is easy. Of course significant usage trumps this comment... Jeff
participants (2)
-
Christopher Kohlhoff -
Jeff Garland