> -----Original Message----- > From: Jeff Garland [mailto:[EMAIL PROTECTED]] > I agree that multiplexing has to be in the design thoughts and > ultimately part of boost, but I worry it will be too much > to deliver, test, and review in the first pass. And, > I see no way I would use Boost.Socket for any non-trivial > server in the near future b/c there is no way it will have > all the elements provided by something like ACE to support > server development.
I don't know exactly what you mean by "non-trivial sever" and what you get from ACE/expect not to get from Boost.Socket that a non-trivial server requires? Is this a maturity of implementation issue or a functionality one? We managed to discard ACE (there was a fair bit of it we didn't want/need and some that needed fixing) and use implementations of the reactor, connector and acceptor patterns based on modern C++ facilities. This is used in servers that may or may not be considered "trivial" but certainly couldn't be implemented using a simple thread-per-connection model. > > That said, I would love to see the multiplexor design > pushed forward, but not at the expense of porting, testing, > and documenting the socket core. Fair enough. > > > Another thing is I think it is important to get at least one > > non-Sockets-based network API in the mix right at the beginning to make > > sure the design is truly flexible. I recommend Apple's OpenTransport, > > not because it will be around much longer, but because it is quite a > > bit different from Sockets, and in order to support it we will have to > > think outside of the Sockets domain. Particularly with issues like > > multiplexing, this would put into perspective just what needs to be > > done, rather than assuming we should just provide an analog for > > select() and be done with it. > > Is there a reference you can add to the Wiki? > > http://www.crystalclearsoftware.com/cgi- > bin/boost_wiki/wiki.pl?BoostSocket/References > > > At the very end of it, network programmers should be using a > > callback-driven interface and not have to worry about multiplexing at > > all, but I agree that for now a third layer should be deferred until > > the basic groundwork has been laid out. Isn't multiplexing a form of callback interface (reactor pattern)? Or do you mean async-io (proactor)? I'd definitely consider trying to implement a portable async-io library to be a step too far at this stage. > > I believe we agree :-) BTW, I've been thinking for awhile that either > boost::function or boost::signal will provide us with core of that > callback framework that diverges from the traditional OO approach > taken by ACE and as is proposed currently on the Wiki. I tried to discuss this here before - maybe I should put stuff up on the wiki instead? The lib I talked about above does precisely that. Given the ubiquitous boost shared_ptr and function and a bit of design something a less ugly than ACE pops out fairly easily. We were inspired by and initially used boost::signal but found we didn't get any benefit from it in this particular case. > > Jeff > > Jeff > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost