- The lack of a standard distribution system - like Perl's CPAN and RPM.
- The Tiny/Minimal Core versus Batteries Included Core issue. We seem to have a compromise solution at the moment, that neither side is entirely happy with.
- The stagnation of certain aspects of Tcl - like skinning/theming of the core widgets, for example.
- The poor documentation of many of the core commands, widgets and concepts.
- Outstanding issues regarding TEA and CVS and how to create packages and enhancements to Tcl. In other words, the architecture and mechanics of how one goes about adding extensions to Tcl.
- The continual talk/work on megawidgets and MegaWidget Librarys.
- And there may well be many more. If there is, just let me know.
daapp 2004-04-24:I suggest to use following scheme:
- the tcl standard library [TSL] should include only one object-oriented extension. This extension can be compiled or pure Tcl, it doesn't really matter from a specification point of view. From a performance and foundation point of view, it probably should be compiled, either initially or at least eventually. This extension should not be written in a way that other object-oriented extensions are made impossible to develop and use.
- TSL should include a megawidget framework, based on the object-oriented extension
- TSL should include the tools and modules for documentation creation and convertion into other formats
- TSL should include the tools and modules to create skeletons for new modules and to work with a network archive of other code
- TSL should include the tools and modules for easy compilation (where appropriate) and installation of extentions
- [fill in other needs here]
- XOTcl for the OO framework [anyone want to explain _why_ the choices here were made?]
- Namespace MegaWidgets or Snit like Delegation in XOTcl or create something new using XOTcl
- doctools, but with xhtml output included :)
- modules framework, which needs to be created from stratch - perhaps based on starkits however as well as TEA2 directory structure
davidw I'd rather create a mailing list than use wiki's for discussion, but here are some of my thoughts on the matter:Worse is Better! - let's get something working, and save the more contentious pieces until later.Every module should have one or more people willing to take responsibility for it.Every module should attempt to harmonize on a documentation standard.Every module should have some tests demonstrating its functionality.Every module (except where obviously not appropriate) should function on MacOS X, Linux/BSD/Unix and Windows.Every module should have a BSD or compatible license.Initial candidates: thread, TclX, XML stuff, tcl big number package, udp extension.SS: 25Apr2004: David, I fully agree with you, but I've to note that worse is better works well if we are ready to change interface from time to time, in an incremental way, without to worry about 5 years old code that no-one is using will stop to work. Corporate's code can just use old versions of Tcl if they don't want to update the source code. Opensource projects MUST update the source to be compatible with a recent release of Tcl, if they don't do it, they are probably dead projects that no one is using anyway. I see a very big inertia in the Tcl comunity to change interfaces, so for the fear that old code will not work, we get that new code will never be written because we can't improve (fast) enough Tcl. This is a bit polemic but I force a bit the things to make my point clear.Peter Newman 25 April 2004: Thanks for your comments SS. See below how I've switched this page to Tackle. P.S. I like the great code you've been uploading to the Wiki. The Alists and that GIMP thing are both useful.SS: 25Apr2004: Thank you Peter, I'll moving the comment in the new Page.
daapp: Using Starkit for distribute modules will be a good idea, but this time standard library must include support for Starkits.About choice that was made, it was only my vision (not a recommendation); nothing else.I agree with davidw; we need something that will work, after that we can polish it.About license: I think because Tcl is under BSD license, every module must be under that license.About other modules, mentioned by davidw: let's look at this variant - we have small TSL that helps to develop not applications, but other libraries, and make other libraries using TSL: megawidget library, network library, text processing library, etc...What do you think about this?
Peter Newman 25 April 2004: This page continued at Tackle.
Tba: But Tackle doesn't actually help here. Splitting the core of Tcl into packages may be the 'right' thing to do but after following this thread and thinking of how it'd be great to have a standard to write packages to, the idea of waiting a year for someone to pull the core apart before progressing just makes my heart sink.I can code C/C++ and Tcl and have written my own C extensions for Tcl and would be happy to help write them for a standard repository but I use Tcl, warts and al, as it is and Tackle wouldn't help me in any way.So any chance of continuing with ideas for a Tcl Standard Library Specifcation (that I'm probably not qualified to make suggestions for but would like to follow).LV what aspects of the tcl standard library specification is it that you want to see discussed? Add some questions and concerns here and see if any discussion ensues. I'll throw out that TEA (well, technically, TEA2) defines a directory structure towards which a Tcl package designer should aim. Take a look at the sample extension housed at SourceForge for a Tcl/C framework that can be used when building a new Tcl extension.
Tba: Things like standard ways of coding commands. For example, I use foxpro/dbase tables a lot at work which don't have an SQL way to access them so I've worked out how I want to access them and written my extension appropriately. But if there were other, similar, forms of storing data then my method may be different. It'd be good if we could think of standard groups of extenstions and a standard way of writing them.Someone mentioned the often wanted udp extension which will obviously follow the tcl socket methods, but other extensions aren't always so easy to know how to write.Also, I don't have the resources to host or design a CPAN equivalent, but it's a damn good idea. There's an email extension out on the web that I found that is great but it took a few attempts to find.Tcl's great and it's often not too hard to take a C API and write a wrapper for it and I'd be happy to write some if I thought I could get feedback on the code and that it'd get used.