apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <trawi...@bellsouth.net>
Subject Re: OK...
Date Fri, 17 Nov 2000 00:20:12 GMT
"David Reid" <dreid@jetnet.co.uk> 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 | trawick@ibm.net | PGP public key at web site:
          Born in Roswell... married an alien...

View raw message