From: jeff_hobbs@my-dejanews.com
Subject: TEA Summit Notes
Date: 22 Mar 1999 09:50:46 -0800

Here are some notes on Tcl Extension Architecture (TEA) Summit that was
held at Scriptics on March 15/16.  For background, and those in attendance,
see:

	http://www.scriptics.com/tea-summit/

The 2 days were broken down into several sections where members of the
Scriptics engineering staff presented background info to the current status
of the item (ie - Configuration and Makefiles) and then moderated the
discussion surrounding the issues.  I'll go through them topic by topic,
covering major points and preliminary outcomes.  Each session had a set of
slides, which Scriptics might be nice enough to post, but I won't otherwise
elaborate (read: retype) the whole set here.

NOTE: I am guaranteed to miss certain things, but please keep responses on
topic.  Use "RE: <Topic Point>" when replying to KEEP THREADS DISTINCT.
Also note that when I say I guess|think|believe|<fuzzy logic here> then
that really means me, Jeff Hobbs, not Scriptics per se.

** TOPIC 1: Ouster Chat -

John gave use a shortened version of what he normally presents at the Tcl
conferences.  On point of interest is that Scriptics currently has only 4
core development engineers, that means engineers on the Tcl core, compared
to 10-12 that were available at Sun.  Keep this in mind next time you
complain about slow integration of new features.  Of course, also keep in
mind that Scriptics is still hiring (they've got expansive new digs in
Mountain View).  Scriptics is definitely in a major growth cycle.

Even with the limited resources, they've managed to continue with 8.0/1
parallel development while also creating tools like TclPro.

 * Why is their a parallel 8.0/8.1 development thread?

This question doesn't have the simplest answer.  The core Scriptics team
left Sun with 8.1 in a very immature state.  John initially wanted to focus
on 8.1 and get the first TclPro out for 8.1, but realization came that by
the time 8.1 was stable enough, Scriptics could deep-six.  So, 8.1 was
continued because it had important key new features (ie Unicode), but 8.0
was (is) being carried along further than originally intended because it is
the base for TclPro.

My guess is that when TclPro makes the move to 8.1, 8.0 will finally drop
by the wayside.  This dual-path certainly hasn't helped alleviate the
crunch on Scriptics limited resources.  Also, it was noted that 8.1 has so
many core changes from 8.0 that it would have been better to call it v9.
This is one reason stubs will be in 8.1 and not back-ported to 8.0.

Scriptics hopes to improve items like transparency into the bug fixing
process and communication between Scriptics and the community as a whole
(both paying customers and open source).

The issue of a possible Tcl Advisory Board was raised, and quickly
scuttled.  It's usefulness was in question, especially after the flames
that arose around the Tcl Consortium.  I feel that Scriptics was hoping for
a moderated view into the community pathos, but it looks like they will
just wade into the consciousness hip deep.

 * Why are we here?

The purpose of the TEA summit arose from problems that exist in the
extension management today.  I even got an "I told you so" in on this.  The
Scriptics guys, who have not been keen on breaking things into packages for
the Tcl core (ref kernel/core discussion), have finally had to deal with
this when integration bundles into TclPro (which now bundles with incrTcl,
TclX and Expect).  On average, it required 2 engineer man months to
integrate an extension into TclPro cleanly.  Basically, Tcl is easy to
extend, but with so many variations on the packaging theme, actually
merging this together wasn't dead simple.

TEA hopes to make it so.

** TOPIC 2: Stubs

Stubs.  First, what are they?  Well, the simplest answer is that they
provide a platform-independent backlinking mechanism.  See Duffin's very
long commentaries on his posts for more exact semantics.

Important aspects of stubs are that is provides forwards compatability
through its pointer table(s), meaning no (much much less?) worries about
future changes in C APIs.  Scriptics plans to also provide function stubs
for 8.0 of UTF and a few other items, so extensions should be able to
compile and run against both 8.0 and 8.1 equally.  Stubs won't be for
everyone, but should make extensions easier for most.  The actual Stubs
mechanism is new in 8.1b2.

** TOPIC 3: Makefiles and Configure

The use of cygwin as a cross-platform solution was raised.  The Scriptics
guys will be surveying c.l.tcl in the near future to see who would be
willing to use it.  Basically, it means the ability to use configure and
make equally on Unix and Windows, when one has the free cygwin tools.

It was recommend that Scriptics supply a VC++ project file for Windows
instead of the makefile.vc (or in addition to).  I guess Windows guys like
this a lot more than having to resort to nmake on the command line (what a
sad state of affairs...).

In general, the ability to use native tools (VC++ being considered the
"native tool" for Windows) is important, with gcc as an option.

The basic features of the makefiles and tclConfig.sh are to change in the
coming versions for TEA.  No more --with-tk, and --tcl-path as a search
path for various Tcl things were recommended.  The Makefile will have
DYNAMIC and DEBUG defines, allowing for the removal of --enable-shared and
--enable-symbols from the configure.  The recommendation was to have four
sub-directories:
	dynamic, dynamic-debug, static, static-debug
with makefiles that support the right options for each in them.

Makefiles in general should all have the following targets:
	all, man, test, dist
	install, install-binaries, install-libraries, install-man
	clean, distclean, setup (build binary dist of extension)

The makefile default will be to use dynamic libs by default where
supported.  tclConfig.sh will have the info for all 4 variants.  I
recommended that tclConfig.sh was built into the tclsh tcl_platform
variable, but that didn't fly for some reason.  I still think that the
ability to have binaries named tclsh8.1, tclsh8.0, tclsh8.0d, etc all know
internally the tclConfig stuff (which is only the one file) makes sense to
me.

The Scriptics guys also want to be able to support static builds on
Windows.  Also, getting rid of any dependency on environment variables that
find the init files would be nice.  In general, the tcl_findLibrary call
should be used by extensions.

** TOPIC 4: Test Suites

Test suites should actually cover source code and be maintainable.  The
tcltest namespace and extension will be packaged with Tcl in the future.
The area of testing is important, and Tcl can make much better headway this
way.  There is a new doc on writing test suites in the tests subdir
(README, it'll probably get a better location soon).  Further hints on all
this stuff will be in TEA.

** TOPIC 5: Installation

Wouldn't it be nice to just say:

	package require Expect

and when it doesn't exist, have a dialog come back asking if you want to
install it?  This has been used in apps like Netscape, and may become a
reality in Tcl in the future.  Until then, the issues for TEA are to
standardize everything down to the minutiae, so that automatic builds can
be guaranteed.

Also, the focus should shift to more binary distributions, with perhaps
even a method to upload to a special site that builds the binaries for you.
A standardized Tcl archive will be formulated in the (near) future to get
this all kick-started.  An installer of some sort will also find its way
into the Tcl core to support this.  More to come as the individual points
are finalized.

Oh, one thing - it should be assumed for extension writers that Tcl will be
installed (and Tk for Tk extensions) already.

** TOPIC 6: Miscellany & Closing stuff

It looks like XML will be the future doc format for the Tcl core and its
extensions.  In this case, the core will provide conversion utilities for
XML->nroff/HTML/rtf, etc as appropriate.

One important item that Scriptics was ambushed with was printing support.
It was noted by most extension authors to be a key issue.  Scriptics got
the message I believe, but their expertise on and resource for this is slim
at the moment.  Any volunteers?  It was noted that just 100% proper canvas
printing was essential, and the text widget after that.  More than that
would just be having the ability for Tk extension writers to access the
necessary primitives in a cross-platform manner.

CONCLUSION

This is the start of a process which will take a bit to reach finalization.
Scriptics is aware of the importance, and will be devoting core engineer
time to realizing the issues above.  Some are already done, others are
well-formed or out in open source, and others are still pie in the sky
ideas.

With coordinated community effort, especially among extension authors, it
looks like we should be able to reach concensus on outstanding items and
develop the Tcl Extension Architecture to the benefit of every user.  We
need to eliminate the idea that adding a C extension is anything more than
a simple turnkey solution, and take Tcl to the next level.

    jeff.hobbs @SPAM acm.org
    jeffrey.hobbs @SPAM icn.siemens.de

[[Send Tcl/Tk announcements to tcl-announce@mitchell.org
  Send administrivia to tcl-announce-request@mitchell.org
  Announcements archived at http://www.findmail.com/list/tcl_announce/
  The primary Tcl/Tk archive is ftp://ftp.neosoft.com/pub/tcl/ ]]