Christopher Kohlhoff <chris@kohlhoff.com> writes: [snip]
- send and recv have been replaced by write and read respectively. Functions called send and receive have been retained on the socket classes with an additonal flags argument.
Why not use the same names (read and write) for the flags versions, either by giving the flags parameter a default value, or by adding an additional overload?
On the datagram_socket, sendto has been renamed to send_to, and recvfrom to receive_from.
Perhaps sendto and recvfrom functionality could be provided by additional function overloads using the same names read and write. This would allow better naming consistency.
- timer has been renamed to deadline_timer and redesigned to use Boost.Date_Time classes.
- socket_connector has been dropped in favour of connect/async_connect functions on both stream_socket and datagram_socket.
It seems that it might be useful to design the interface in regards to connect such that the user does not have access to methods, such as read and write, when the cannot be used. This could be achieved by providing the user with an object that provides the read/write interface only after connect completes. The socket class itself would not have these functions. I haven't thought this through very much, but it seems like something worth considering. Another related idea is to provide two separate `stream' objects for regular and out-of-band data for TCP. It seems like this could potentially allow for a cleaner interface for sending out-of-band data, but I have also not thought this idea through fully.
- async_get_host_by_address and async_get_host_by_name functions have been added to ipv4::host_resolver. The implementation is simple and only simulates asynchronicity (using one background thread per-demuxer to execute the corresponding blocking call).
What about using platform-specific asynchronous name resolution facilities? [snip]
- The "services" have been made part of the public interface of asio. E.g. for basic_stream_socket there is a stream_socket_service. These services are also templates and have an allocator as the template parameter (although this currently has no effect on the implementation).
In what case would some other `service' be used for basic_stream_socket? [snip]
After pondering for some time, I think I have devised an approach that meets both requirements. The approach is loosely based on Symbian's TPtr/TPtrC classes.
[snip] One comment is that the types returned by make_buffer should be known to the user and easy to type, because the sub-buffer methods seem to be primarily useful in the case that the result of make_buffer is stored in a variable rather than passed directly to read, write, and not everyone wants to use templates to avoid having to type types. -- Jeremy Maitin-Shepard