"David Reid" <[EMAIL PROTECTED]> writes:
> Just a thought, should we define the socket families as APR values? This
> would mean that on a non-v6 platform we could still call create socket with
> APR_V6 as a family and we'd just return an error. Don't know if it makes
> sense or not...
sure... at config time we can figure out the right values and
stick them in apr.h I think; on a system with no AF_INET6 we wouldn't
want to accidently set APR_V6 to the value for an address family it
actually has :) I'm punting on this for now
> Also, do we want to be able to pass in a servicename for the port?
> Otherwise I think we should add a function to get the numeric port for a
> service name...
On the one hand, it would be nice to pass it in to apr_getaddrinfo()
since on platforms with the real getaddrinfo() we can pass it on
through and magic happens. Unfortunately, I think apr_getaddrinfo()
is going to get darn ugly what with the series of functions we try at
config time and to a lesser extent at run-time (for
!GETHOSTBYNAME_HANDLES_NAS) just to resolve the hostname/numeric
address string.
A separate function is probably simplifying overall.
> > There is no flags parameter for now, but we may need to allow that
> > eventually.
>
> If we think we'll need it should we add it now so we don't break the API
> when we do?
>
will-do (but Greg S. doesn't like that style so if he reads this then
watch out :) )
> > > > 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 makes sense.
>
> +1
I'll hold off on that one for now (until after the alpha maybe?). I
need to spend some time making an honest attempt at not breaking Win32
and OS/2 when I ship this patch.
--
Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
