On Friday, February 14, 2003, at 08:38 AM, Jeff Garland wrote:
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. 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.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.
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.
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.
-- Brian
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
