Re: OK...
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...
Re: OK...
David Reid [EMAIL PROTECTED] writes: [OK, I'm getting better at this Reply To All stuff...] I still haven't gotten the hang of it :( Maybe I need to study the GNUS manual to figure out how to avoid editing the cc line to keep me out of it. 1. Modify connect to take an apr_sockaddr_t instead of a hostname... This is a simple change so I'll make it sooner rather than later. yes... OK, I've done some work on this but am getting an error now Could not connect: Can't assign requested address (49) I've got to drive to Suffolk in a short while so I'll post the patch at the end of this message and let someone else figure out where I've screwed up! :) I'll start working on that. 2. Are we agreed on Jeff's suggestions of Add apr_pool_t * to apr_sockaddr_t. apr_status_t apr_get_address(char **hostname, apr_interface_e which, apr_socket_t *sock); apr_status_t apr_get_nas(char **addr, apr_sockaddr_t *sa); These are new additions sos houldn't interfere with any existing code. I am. Good. There was an implied :) after I am. more comments on the rest later... for now I'll look at apr_connect() and make an attempt at fixing the Win32 and OS/2 builds to include apr_inet_ntop() and apr_inet_pton(). -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: OK...
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
