> On Friday, February 14, 2003, at 08:38 AM, Jeff Garland wrote: > > So in summary, I think we should focus the Boost.Socket effort > > on what is currently described as 'level 1 - OS platform layer' > > and 'level 2 - basic connectivity layer' leaving multiplexing > > for later. I'm sure this will be controversial with some, but > > it seems to me that this is the only reasonable approach for a > > boost library daring to tread into a complex domain. > > I disagree. By failing to provide support for multiplexing, we limit > ourselves to clients and servers small enough to follow the > one-thread-per-connection approach.
Yep, but it is a much bigger domain than being served now... > Multiplexing is absolutely essential for writing even moderately > complex servers. Unless you're saying the user could mimic > multiplexing by manually looping through a vector of non-blocking > sockets, polling for activity. That would work, but I still say > that at the very least multiplexing should be worked into the > design, perhaps implemented as a simple looped poll at first, > then done correctly later. 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. 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. > 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. 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. Jeff Jeff _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
