Giovanni P. Deretta wrote:
I think that the most important innovation of asio is the dispatcher concept and the async call pattern. Everything else is just *extra*. Yes.
The {datagram|stream}_socket interface is nice, but i have some issues with them.
Also i think there should be *no* asio::stream_socket. This is my major The current stream socket should be in the namespace asio::ipv4, and should be a different type for example from an eventual asio::posix_pipe::stream_socket or asio::unix::stream_socket. Yes. I think the interface could be extended for better efficiency (i will try to describe later how), but this can be done at a later stage. Yes. I don't really like a lot the service concept. While I agree that the service repository is useful to hold the various proactor implementations (iocp_service, reactive_service<kqueue>, reactive_service<epoll>, etc...), i don't think that the streams should care about them. As long as the impl_type are interoperable, any stream should be bindable with any service. This also means that the binding with the demuxer should *not* be done at creation time, but at open time. This will make it possible to have different openers: connector, acceptor, unix::socket_pair, posix::pipe etc. The openers are instead created with a demuxer reference and will pass it to the socket when opened. By the way, the implementation of socket functions (accept, connect, read, write, etc) should not be members of the demuxer service but free functions or, better, static members of a policy class. Yes - I was trying to figure out how to fit that into the current design, sounds like a good approach. The current interface let the user put a socket in non blocking mode, but there is not much that can be done with that, because no reactor is exported. The various reactors/proactor implementations should be removed from the detail namespace and be promoted to public interfaces, albeit in their own namespace (i.e. win32::iocp_proactor, posix::select_reactor, linux::epoll_reactor etc...). This change will make the library a lot more useful. Yes.
I just wanted to endorse this in the hope that your slant on it makes more sense than mine. I think (haven't had a proper look at it to be sure) your suggestions address my major concerns with the library. Regards Darryl Green. -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.9/217 - Release Date: 30/12/2005