-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hrvoje Niksic wrote: > 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)?
I'm having some trouble seeing how most of those present problems. Obviously, you wouldn't call _any_ system functions on these, so yeah, no setsockopt() unless it's a wg_setsockopt() (a wg_setsockopt would probably be a poor way to handle it anyway, as it'd be mainly true-TCP specific). I don't see what you see wrt making the code harder to follow and reason about (true abstraction rarely does, AFAICT, though there are some counter-examples, usually of things that are much, much more abstract than we are used to thinking about). Did you have some specific concerns? I _am_ thinking that it'd probably be best to forgo the idea of one-to-one correspondence of Berkeley sockets, and pass around a "struct net_connector *" (and "struct net_listener *"), so we're not forced to deal with file descriptor silliness (where obviously we'd have wanted to avoid the values 0 through 2, and I was even thinking it might _possibly_ be worthwhile to allocate real file descriptors to get the numbers, just to avoid clashes). Then we can focus on actual abstraction (which we don't obtain by emulating Berkeley sockets), rather than just emulation. While Daniel was of course right that we'd need listen, accept, etc, we _wouldn't_ need them to begin using this layer to test against http.c. We wouldn't even need bind, if we didn't include --bind-address in our first tests of the http code. >> 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. Why? - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer, and GNU Wget Project Maintainer. http://micah.cowan.name/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH+Eoi7M8hyUobTrERAj3VAJ4vb/SPNkNo+Xyd2Hq09U4ey6zJJwCfVmG0 NSVpzr7IEdpUQkTwy/j2z9E= =9lKJ -----END PGP SIGNATURE-----
