Re: [boost] [network] Boost.Network proposal v0.2

From: Pedro Lamarão (pedro.lamarao_at_[hidden])
Date: 2005-07-07 09:16:24

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