> 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?
Depends on the server, CDR formatting, thread-safe queues come to mind. There are probably a few threading things as well. Of course all of these can be built, but spending time building this sort of infrastructure detracts from time spent developing the actual functionality. >Is this a maturity of implementation issue or a functionality one? Yes, this is a huge factor. A project I worked on using ACE has been deployed for over 5 years with no problems. > 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. No question it can and should be done, and hopefully part of boost. > > > 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. Yes, and even I agree it would be best to have some basic multiplexing in an early version of the library. However, there are tremendous platform/portability issues in multiplexing and I'm just afraid in another 6 months we still won't be anywhere if we try to do it all. > > 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. Please, the Wake is currently the point of collection. And then drop a notification on the mailing list so we'll all go and respond. Jeff _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
