Re: Forms support in clients

Brian Behlendorf (
Mon, 26 Sep 1994 08:08:49 +0100

On Mon, 26 Sep 1994, Nick Arnett wrote:
> >No - he wants documents that can be more like programs. basically he
> >wants to display the form, have the user fill in what doc he
> >would like (as an example) and then have the browser do a text
> >substitution on the ACTION part before performing the GET.
> There's been some talk around here, as I vaguely recall, about TCL for this
> sort of thing. Any thoughts, anyone, on the idea of letting TCL swallow up
> HTML, so that we have a real UI language that contains a real hypertext
> language, instead of trying to built a UI language out of a hypertext
> language? (Which just ain't gonna happen, I suspect...)

Tcl isn't a "real GUI" language - not to start any language wars, mind
you, but I think the reason people mention Tcl and GUI in the same breath
is Tk, which (though I haven't played with it yet) is a GUI class library
which runs under Tcl (Tcl:Tk::C:Motif, in other words). Last I heard Tk
was being ported to Perl as well (TkPerl). Another, more complete
solution is something like WINTERP, a LISP-ish language with integrated
user interface capabilities.

If we want a real UI language, we want to get away from the notion of
delivery of static documents. Not a bad idea, just not something there's an
easy answer for - and I should reference all the debates about scripting
languages and security that have happened here before. HTML simply isn't
about GUI's or being pretty - it's strength, in my opinion, is in its
flexibility across a wide array of platforms and giving the user the
ability to control a large part of the presentation. I can't reconcile
that quite yet with a "real GUI" language, and I don't know that it's
possible. The way I see it, there are three things that'll give us about
all we need in terms of functionality:

1) HTML (with extensive presentational hints, improvements in many areas
- I'll probably be satisfied by the time HTML 4.0 comes around :)
2) Acrobat/HyperPostscript/some-other-document-language-that-assumes-complete
3) Browser plug-in modules to extend GUI functionality in a standard way,
and explicitly installed by the user (the "Acrobat" plug in, the
"AOL interface" plug-in, etc.) I don't subscribe to the notion that
the information provider should have automatic control over that

There may be battles between 2 and 3 if not designed well.