> > > > 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.
+1 for this and your subsequent patch. 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... 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... > > 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. If we think we'll need it should we add it now so we don't break the API when we do? > > > > 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 > > 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. david
