Re: [boost] sockets Interface for address class

From: Iain.Hanson_at_[hidden]
Date: 2002-02-28 14:21:06

from my previous post.

>>This seems fine, as long as your resolver design allows for a >succint 
>>syntax with the socket address class so that users aren't motivated 
>to avoid deailing with hostnames -and- dotted decimal names out of 
>>laziness.
>>
>>In other words, 
>>
>>resolver r("www.boost.org");
>>socket_address a(r.get_primary_addr());

>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.

What I meant by layered on top of would probably be containment and certainly 
not inheritence. A resolverable_address would be constructable from DNS names 
whereas the address class currently under discussion is only constructible from 
dotted decimal strings such as "10.0.0.1"

A resolver class will need to deal with address_info and have iterators etc. but
thats getting ahead of myself.

/ikh

______________________________ Reply Separator _________________________________
Subject: Re: [boost] sockets Interface for address class
Author:  boost (boost_at_[hidden]) at unix,mime
Date:    28/02/02 15:34

On Thu, 2002-02-28 at 13:32, Iain.Hanson_at_[hidden] wrote:
> As I posted previously, This is more the job of a resolver class and could 
> also be layered on top of this address class as a resolvable_address.
     
Sorry, I missed that one.  How about calling them resolved_address and 
address? I expect most people will want to work with unresolved 
addresses.
     
Also I think they should be two different things not derived from one 
another (if that is what you meant by "on top of"). Constructing an 
unresolved address should not mean resolving it.
     
You could resolve the address something like
  address unresolved;
  resolved_address resolved;
     
  address_info_list list( resolver.resolve( unresolved ) ); 
  if( list.size() == 1 )
  {
    resolved = (*list.begin()).resolved_addr();  
  }
     
Short hand for this could be 
  resolved = unresolved.resolve_single( resolver );
(The resolver argument could have a default to make it even easier) 
This function would have to throw if list.size() != 1.
     
However, I think most high level functions should actualy accept 
address_info and address_info_list as they would contain the information 
required to call socket.
     
Another possibility would be to have three classes resolved_address, 
unresolved_address and address.  Where address is something like
     
class address
{
  bool is_resolved_;
  resolved_address resolved_;
  unresolved_address unresolved_;
public:
...
};
     
Hamish
     
     
Info: http://www.boost.org  Send unsubscribe requests to: <mailto:boost-unsubscr
ibe_at_[hidden]> 
     
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 
     
     

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.