Re: [boost] asio formal review

From: Christopher Kohlhoff (chris_at_[hidden])
Date: 2005-12-14 06:38:13

Hi Eugene,

--- Eugene Alterman wrote:
> That's precisely what I've anticipated to come up next . :-)

So I take it your happy with the changes then? I'll try to make
the change for the next version of asio. I'm still not happy
with the naming, but assuming those names I would have:

typedef basic_stream_socket<
  stream_socket_service<> > stream_socket;
typedef basic_core_socket<
  stream_socket_service<> > core_stream_socket;

> I just want to provide an illustrating example. This is an
> actual situation I encountered while experimenting with asio
> that prompted me to advocate these changes.
>
> I was trying to write a server that would run over a regular
> tcp connection or a secure connection depending on a run-time
> program option. I created an abstract base session class that
> contained all the transport-independent processing logic. It
> had a pure virtual function that I misleadingly named socket()
> returning a tcp socket to be used by the acceptor. Then I made
> a stupid mistake - instead of also providing virtual functions
> for i/o I started using socket() for that. You can imagine
> what I ended up with on the secure server!.
>
> The proposed changes would have prevented me from making such
> a mistake.

So under the new scheme you would instead write something like:

class session : public abstract_session:
{
public:
  ...
  virtual core_stream_socket& socket()
  {
    return socket_.lowest_layer();
  }
  ...
private:
  ssl::stream<stream_socket> socket_;
};

Of course it occurs to me that if the socket() function on your
class was instead named lowest_layer(), the socket_acceptor would
be able to operate on your session class directly.

I'm also starting to think that if next_layer() is going,
lowest_layer() is not the best name. Any suggestions for an
alternative? It has to be something independent of sockets since this
concept should apply to other things like files too.

Cheers,
Chris