Micah Cowan <[EMAIL PROTECTED]> writes: >> Or did you mean to write wget version of socket interface? i.e. to >> write our version of socket, connect,write,read,close,bind, >> listen,accept,,,? sorry I'm confused. > > Yes! That's what I meant. (Except, we don't need listen, accept; and > we only need bind to support --bind-address. We're a client, not a > server. ;) ) > > It would be enough to write function-pointers for (say), wg_socket, > wg_connect, wg_sock_write, wg_sock_read, etc, etc, and point them at > system socket, connect, etc for "real" Wget, but at wg_test_socket, > wg_test_connect, etc for our emulated servers.
This seems like a neat idea, but it should be carefully weighed against the drawbacks. Adding an ad-hoc abstraction layer is harder than it sounds, and has more repercussions than is immediately obvious. An underspecified, unfinished abstraction layer over sockets makes the code harder, not easier, to follow and reason about. You no longer deal with BSD sockets, you deal with an abstraction over them. Is it okay to call getsockname on such a socket? How about setsockopt? What about the listen/bind mechanism (which we do need, as Daniel points out)? > This would mean we'd need to separate uses of read() and write() on > normal files (which should continue to use the real calls, until we > replace them with the file I/O abstractions), from uses of read(), > write(), etc on sockets, which would be using our emulated versions. Unless you're willing to spend a lot of time in careful design of these abstractions, I think this is a mistake.
