[5777] in www-talk@info.cern.ch

home help back first fref pref prev next nref lref last post

Re: Forms support in clients

daemon@ATHENA.MIT.EDU (Brian Behlendorf)
Mon Sep 26 03:14:29 1994

Date: Mon, 26 Sep 1994 08:11:59 +0100
Errors-To: listmaster@www0.cern.ch
Errors-To: listmaster@www0.cern.ch
Reply-To: brian@wired.com
From: Brian Behlendorf <brian@wired.com>
To: Multiple recipients of list <www-talk@www0.cern.ch>

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
	-control-over-presentation
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 
	element.

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

	Brian

home help back first fref pref prev next nref lref last post