"David Reid" <[EMAIL PROTECTED]> writes:
> > > This would then give
> > > apr_sockaddr_t *sa;
> > > apr_gethostbyname(&sa, "hostname", pool);
> > > apr_connect(sock, sa);
> >
> > We need to add more arguments: address family for sure and possibly
> > flags. Look at getaddrinfo(). And do we want to add an optional
> > service name/port number parameter? That would build the complete
> > sockaddr for us.
>
> OK. Care to suggest the definition?
apr_status_t apr_getaddrinfo(apr_sockaddr_t *sa,
const char *hostname,
apr_int32_t family,
apr_port_t port,
apr_pool_t *p);
hostname is one of three things:
a) ptr to DNS name
b) ptr to numeric address string
c) NULL if we don't have a name/address and just want to build a
sockaddr with address INADDR[6]_ANY and some port.
family is AF_UNSPEC if we don't care, AF_INET or AF_INET6 otherwise.
You can't have hostname == NULL and family == AF_UNSPEC.
port will be stored into the new sockaddr; pass zero if you don't
care.
There is no flags parameter for now, but we may need to allow that
eventually.
> > In addition to the changes you mentioned, I see apr_create_socket() as
> > extremely important in the short run and I think we should think about
> > apr_bind() working like apr_connect() (in other words, taking an
> > apr_sockaddr_t). That makes sense when the user has told us the local
> > interface address and we have to resolve it anyway. We have to keep
> > it from being painful when we just have the port number.
>
> OK, so again care to suggest the API definitions?
I think apr_connect() is good the way it is.
For apr_bind(), I see it looking like apr_connect():
apr_status_t apr_bind(apr_socket_t *, apr_sockaddr_t *);
Why?
This allows an app to use apr_getaddrinfo(), which will allocate a
socket address, store the port in the right place, and perhaps
handle a local interface address specified by the user.
--
Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
