$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: dmoore99atwork (dmoore_at_[hidden])
Date: 2002-02-27 09:42:27
      
> >Are you talking about marshalling of the individual members of the 
> >underlying socket address representation, or all marshalling of 
data 
> >that will eventually take place on a connection to this network 
> >address?  If you're just talking about the representation of the 
> >address, I would say that this is a degree of freedom that is not 
> >needed for real world sockets stuff...
> 
> I'm refering to marshalling network & transport address ( port ). I 
> would say that this degree of freedom is necessary because it is 
> possible to build an address with either premarshalled data or 
> unmarshalled data. 
Fair enough, and once I thought about it, this is almost always known 
as compile time.  Might complicate things like assignment operators 
or comparisons, but this is worth it to eliminate the common error of 
missing htons() on a port...
      
> I have only roughly modeled the resolver, so far but yes, I would 
expect it to 
> be at least that simple. I would probably prefer a free function 
that allowed 
> getting the primary directly, such as:
> 
> address Server_Address ( primary_address ( "www.boost.org" );
> 
> maybe at layered on top of this there could be a resolvable_address.
Looks reasonable...  Most people don't need to dig down to alternate 
addresses that the resolver returns, but some people will, and the 
free function keeps it simple for most people...
As for the csocket.h, cinet.h, etc., you'll need one of these for 
each platform flavor, especially for the older IPv4 stuff....  To 
pick a specific example, some versions of BSD have an 8 bit length 
member in the sockaddr_in structure and an 8 bit address_family 
member, while Winsock and other Unices have a 16 bit address_family 
and no length member.
I think you *can* reasonably "size" your structures in a common 
header based on public specifications/standards, but there is no 
getting around the fact that any platform independent library will 
need platform specific structure handling code for variations like 
the one above.
Dave