[5776] in www-talk@info.cern.ch
Re: Forms support in clients
daemon@ATHENA.MIT.EDU (Karl Auerbach)
Mon Sep 26 02:20:39 1994
Date: Mon, 26 Sep 1994 07:14:22 +0100
Errors-To: listmaster@www0.cern.ch
Errors-To: listmaster@www0.cern.ch
Reply-To: karl@cavebear.com
From: Karl Auerbach <karl@cavebear.com>
To: Multiple recipients of list <www-talk@www0.cern.ch>
>>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...)
Please not TCL. It is intrinsicly inefficient and, to my eyes, quite
inelegant.
(My preference is Scheme, but I somehow suspect that this isn't
necessarily going to be popular with People who have been brought
up on shell programming and C.)
Whatever, the language, the important issues are a secure/safe
abstract machine in which it is to execute.
On viewers, I suspect execution efficency isn't particularly important
when talking about display generation or forms. But once the door is
opened a little, some folk are going to want to do more general
computations.
If we talk about execution on the servers or in caches, then I think
we need to be concerned about efficiency.
The larger issue when one starts talking about pushing executable
candy-grams around the network is controlling those that have more
than an extremely short life span.
--karl--
