Re: [TCLCORE] TIP Roundup (162)

[David G. <dav...@po...>]

Donal K. Fellows wrote:

> Remember, the broad strategy is to keep Tcl 8.6 on track for a Spring
> 2009 final release. We took far too long with both 8.4 and 8.5...

Well, then IPv6 won't hit for 8.6 then...  I work a real job, too :)
There is just too much work to do in FIXING the broken stuff BEFORE
adding new functionality.  I haven't even brought up QoS yet.

1) [socket -async foo.example.com 1234] blocks on DNS rather than being
async as requested.
2) proper DNS errors are lost.
3) WinSock code is in dire need of a revamp to a decade ago's methodologies.
4) Tcl_OpenTcp(Client|Server) both take an int value for the port values
instead of a string.  This places a network protocol understanding
requirement into the generic code to resolve port names
(generic/tclIOSock.c).  Not a big deal really, but I'd like to see
either the signatures change, or a new level of indirection so that
protocol specifics don't have be in the generic side of Tcl_SocketCmd().
 True, the BSD socket call getservbyname() is consistent across
platforms, and was probably the reason why Scott Stanton put it there,
but there was extra work on the windows side through C macros to allow
it to go through the winSockProcs function table (now removed by Pat
Thoyts).  But a larger issue exists here that restricts Tcl_SocketCmd
from being the general entry for all network stream creation and even
resolution.  Some network protocols use a tuple arrangement like IPX and
AppleTalk, but I don't really see a problem combining network and node
into the one address string.
5) What's up with UDP and message based channels?