Re: [boost] asio networking proposal 0.3.3

From: Jeremy Maitin-Shepard (jbms_at_[hidden])
Date: 2005-09-02 10:36:11

Christopher Kohlhoff <chris_at_[hidden]> 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