Re: [boost] [asio] Formal Review

From: Darryl Green (darryl.green_at_[hidden])
Date: 2005-12-31 09:12:51

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