Anyone who doubts that [JCW]'s [scripted document]s are way cool clearly hasn't been paying attention.  Over the last six months or so, scripted documents have become, ''de facto'', the standard way to deliver standalone Tcl/Tk applications.  Just browsing about, I even found a copy of my own [expand] application as a scripted document (is anyone using that version?).  Scripted documents allow you package up your Tcl application and all packages it requires into one binary, cross-platform file; and, optionally, create platform-specific executables.  And it works well enough that lots of people are doing it.

But there are problems--not with the technology, so as much as with its presentation.  

   * The name "scripted document" does very little convey what scripted documents are all about.

   * The instructions for creating and using scripted documents are scattered hither and thither.

A potential creator of scripted documents really has to dig, not only to find out how to create them,
but even just to find out what they are good for.

And let's be clear--what we have here is simply a Tcl version of Java ".jar" files, with the runtime
environment optionally bound in.  It works.  It's way cool.  And it's become a standard.  It's time
to tear down the veil of obscurity.

   * We need a better, more communicative name.

   * We need a concise set of instructions for application authors.

-- [WHD]

''Too bad ".tar" is already taken. ;-)  How about ".tap" for "Tcl application package" ? --[MDD]''

''Wow, amazing timing... I'm in the process of documenting, and they already have a new name... As for "simply jar files": not quite, SD's are r/w with transaction-safe commit/rollback because there's a database engine underneath.  That means they can also store config info, update themeselves, or even contain extensive datasets.  -[jcw]''
----
[Category Wikit] | [Category Tclkit] | [Category Scripted Document]