|
From: Donal K. F. <don...@ma...> - 2008-11-21 23:59:08
|
Apart from the TIP vote currently running (if there are adjustments to those TIPs to be done during the vote, send me what you think should change) these are the things that I'm eyeing to do as part of the 8.6 feature set. TIP#162: IPv6 Sockets for Tcl TIP#180: Add a Megawidget Support Core Package TIP#234: Add Support For Zlib Compression TIP#244: PNG Photo Image Support for Tk TIP#281: Improvements in System Error Handling TIP#329: Try/Catch/Finally syntax Now, for the constraints/notes. The big constraint is time: we want to close the window on new features in early December so that we have time to push the implementation into a fit state for an 8.6.0 release in the (northern hemisphere) Spring. This means that some projects are going to be necessarily much smaller than some people think. For example, #162 (IPv6) is really not about the sort of major re-engineering that David Gravereaux envisages, as that would take much more work than we have time to do *even with an implementation ready for one platform*. Given that, getting IPv6 support is actually the issue before us and that's what I plan to call that TIP on. (Yes, a generic plugin architecture for socket types would be neat, as would fixing the blocking-resolver bug. But they're not this TIP.) It's possible that #180 will be purely scripted, maybe not in Tk at all. It certainly needs quite a bit of work to revise once I work out (with Damon?) what is actually not already trivial. (TclOO changes the whole equation quite a bit...) Do not be surprised if this slips and goes into tklib instead. TIP#234 has suffered badly from the bikeshed effect. For myself, I want this sufficiently strongly that I'd be happy to eliminate chunks of the Tcl API (we can do them in the future after all) and do just those parts that we can be sure of. That then enables TIP#244, which is important for Tk. I'm inclined to characterize TIP#281 as more of an approval for what I expect will be an ongoing programme to improve the error handling on (especially) Windows. It's not clear to what extent we should make a new API to support this yet; maybe in 8.6 it is sufficient to keep the added functions internal for later exposure. And finally, I'd like to see TIP#329 go in. Right now, doing stuff with [catch], [switch], etc. is sufficiently messy and ugly that people don't. This results in code that is not as robust. Yes, [try] adds nothing that you can't do now. I expect the first version to be scripted (though I hope to be able to produce a C version before 8.6.0). But the key is that it much more strongly encourages people to do the right thing with error handling (and hence error creation too). Doing the other exception cases is purely a bonus from my perspective. (It does benefit rather from #281...) In order that we may run an orderly vote within our own deadline, the "Big Ticket CFV" will probably be next Friday. If you want to argue about the APIs in these TIPs, *please* get it over with before then! We can't/won't wait for you to resolve some minor point! Donal. |
|
From: Jeff H. <je...@ac...> - 2008-11-22 00:28:22
|
Donal K. Fellows wrote: > TIP#162: IPv6 Sockets for Tcl ... > For example, #162 (IPv6) is really not about the sort of major > re-engineering that David Gravereaux envisages, as that would take much > more work than we have time to do *even with an implementation ready for > one platform*. Given that, getting IPv6 support is actually the issue > before us and that's what I plan to call that TIP on. (Yes, a generic > plugin architecture for socket types would be neat, as would fixing the > blocking-resolver bug. But they're not this TIP.) I have a working patch for this that Pat has vetted. I will try and squeeze out some time this weekend to update the patch (tkchat consensus was to use -family instead of -type for inet4|inet6) against the head(s). Jeff |
|
From: David G. <dav...@po...> - 2008-11-22 01:54:12
|
Jeff Hobbs wrote: > I have a working patch for this that Pat has vetted. I will try and > squeeze out some time this weekend to update the patch (tkchat consensus > was to use -family instead of -type for inet4|inet6) against the head(s). That fits well with socket()'s af, type, and protocol params quite nicely. I like it. A good basis to grow from. |
|
From: Stuart C. <stu...@sy...> - 2008-11-22 02:37:10
|
David Gravereaux wrote: > Jeff Hobbs wrote: > >> I have a working patch for this that Pat has vetted. I will try and >> squeeze out some time this weekend to update the patch (tkchat consensus >> was to use -family instead of -type for inet4|inet6) against the head(s). > > That fits well with socket()'s af, type, and protocol params quite > nicely. I like it. A good basis to grow from. > The name of the first parameter to socket(2) is 'domain'. I can't say I remember a consensus, and this really is a pittance but I'll throw in my CDN $0.02 here and say I prefer -domain -type and -protocol for the simple reason that they follow the names used for socket(2). One could argue that those aren't the greatest names and certainly come up with better ones but I think it's good to have consistency across as wide a swath of environments as possible. |
|
From: Donal K. F. <don...@ma...> - 2008-11-22 02:44:27
|
Jeff Hobbs wrote: > I have a working patch for this that Pat has vetted. I will try and > squeeze out some time this weekend to update the patch (tkchat consensus > was to use -family instead of -type for inet4|inet6) against the head(s). It's not clear to me why that's needed. Couldn't I just use -myaddr to force the issue if I cared and Let Tcl Do The Right Thing the rest of the time? Donal. |
|
From: David G. <dav...@po...> - 2008-11-22 02:57:15
|
Donal K. Fellows wrote: > Jeff Hobbs wrote: >> I have a working patch for this that Pat has vetted. I will try and >> squeeze out some time this weekend to update the patch (tkchat consensus >> was to use -family instead of -type for inet4|inet6) against the head(s). > > It's not clear to me why that's needed. Couldn't I just use -myaddr to > force the issue if I cared and Let Tcl Do The Right Thing the rest of > the time? It goes something like this... A lookup for a site such as "www.kame.org" might return both an inet4 and an inet6 address. The v6 planning docs say to to use the v6 when available, but sometimes you might want to force v4, just cause. And addresses like ::192.68.12.14 are really v6 in disguise, but you might not want the outgoing on a v6 socket. -family forces the hints to getaddrinfo() so you get the result you want. |