Hi all,
I'm looking to resolve this bug, and thought about 2 means in which to
implement the request of exposing C's getaddrinfo() and the addrinfo
structure. There's not really an equivalent means to accomplish this in
userland without trial&error.
So I'm not sure the communities best-practices on altering current userland
function signatures to implement a new feature. So I've devised 2 means of
implementing this feature but don't know which would be preferred. The
former introduces new functions for addrinfo-specific usage. The second
alters current socket_connect/socket_bind signatures. They are both very
similar in their implementation. I'm filling out an RFC[1] for this
addition, and have details of each implementation idea typed out in it for
you to see what I'm trying.
Suggestions and advice on best-practice greatly appreciated.
Dave
Hi all,
I'm looking to resolve this bug, and thought about 2 means in which to
implement the request of exposing C's getaddrinfo() and the addrinfo
structure. There's not really an equivalent means to accomplish this in
userland without trial&error.So I'm not sure the communities best-practices on altering current userland
function signatures to implement a new feature. So I've devised 2 means of
implementing this feature but don't know which would be preferred. The
former introduces new functions for addrinfo-specific usage. The second
alters current socket_connect/socket_bind signatures. They are both very
similar in their implementation. I'm filling out an RFC[1] for this
addition, and have details of each implementation idea typed out in it for
you to see what I'm trying.Suggestions and advice on best-practice greatly appreciated.
I feel the weight of new functions, but really getaddrinfo is meant to both
simplify and unify how sockets are dealt with in the modern era.
socket_getaddrinfo converts the returned linked list into an array of,
essentially, socket contexts. The user can inspect those contexts and
choose the one he wants to use in connect and bind. Simple.
With a few minor tweaks to naming (to lump all the addrinfo functions
together), this makes sense to me:
$contexts = socket_addrinfo_lookup($node, $service, $hints);
foreach ($contexts as $context) {
print_r(socket_addrinfo_explain($context));
}
$socket = socket_addrinfo_connect($contexts[1]);
// ...
So I would lean toward flavor #1. Thanks!
I feel the weight of new functions, but really getaddrinfo is meant to
both simplify and unify how sockets are dealt with in the modern era.
socket_getaddrinfo converts the returned linked list into an array of,
essentially, socket contexts. The user can inspect those contexts and
choose the one he wants to use in connect and bind. Simple.With a few minor tweaks to naming (to lump all the addrinfo functions
together), this makes sense to me:$contexts = socket_addrinfo_lookup($node, $service, $hints);
foreach ($contexts as $context) {
print_r(socket_addrinfo_explain($context));
}
$socket = socket_addrinfo_connect($contexts[1]);
// ...So I would lean toward flavor #1. Thanks!
Bishop,
Thanks, I was really thinking that #1 would be preferred over altering
argument types to long-existing functions. I have updated the RFC to
include only it's implementation as well as changed the function names.
--
Dave