Beman Dawes wrote:
One thing I didn't see was a discussion of the various levels of networking support. Are the components you describe actually implemented in terms of some lower level functionality? Will that lower level be publicly exposed?
We must, of course, eventually reach the operating system. So in a minimalist implementation the streambuf type would contain a socket descriptor and make system calls. It being a template, my decision was to move these, the descriptor and the system calls, into another class, non templated, to be able to hide those inside a library. So, yeah, there is a "socket" type around. It is inevitably accessible, but my intention is to not document it as one of the library's facilities. It's sole purpose is to not show people system calls in header files, and, together with other machinery, completely avoid the system header files where those are declared. I've recently written something about the NetworkAddress concept, and why it exists; I'm now moving to summarize and address some of the points people brought up last time we had a big [network] thread. I think I can categorize those under two bullets: * non-blocking operation mode * primitive operation mode * binary IO The argument for the availability of both is "performance". I'm positive we have no need for "primitiveness" for performance. I suspect a non-blocking operation mode is less useful than the amount of requests would suggest (although, of course, *useful*). For the meaningful values of "binary", IOStreams support "binary" IO just fine. -- Pedro Lamarão Desenvolvimento Intersix Technologies S.A. SP: (55 11 3803-9300) RJ: (55 21 3852-3240) www.intersix.com.br Your Security is our Business