> 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.
How would you describe the differences between Apples OpenTransport and sockets with respects to especially api, options and multiplexings. I think the design proposed on wiki is rather socket centric the upside would be to be able to make an library in wich you could use a larger part of the common interface available with sockets the downside that other api:s would have to be forced into a socket centric one. Could you help out with an early OpenTransport port or at least an early review to evaluate the design with respect to this demand? What do you others have for view on this, isn't the problem domain hard enough with the differences in sockets implementations and multiplexing mechanism on different platforms or should we aim even higher and be able to incorporate other more "exotic" network apis which cannot easily be mapped to sockets? /Michel _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost