Re: Forms support in clients

Marc VanHeyningen (mvanheyn@cs.indiana.edu)
Tue, 27 Sep 1994 06:49:21 +0100

Thus wrote: Karl Auerbach
>Please don't take me as an anti-TCL bigot. Rather, I'm concerned that
>as we load servers with more and more interpretable blocks of code
>that what are tolerable levels of overhead will be vastly multiplied.
>(The standard warning in http daemon configuration documents that
>running the daemon from inetd might not be desirable is a similar
>forewarning.)

Most of the scenarios which I've seen described involve the program
being executed on the client side, though doing things on the server
side is an interesting possiblity (can't think of many scenarios for
it offhand...) It occurs to me that we might be talking about
entirely different issues.

Part of it depends on the current producer-consumer model. If you
stick to that, the idea is for the producer to give a level of
interaction that is not practical if continuous server contact is
needed. The Parc map server is cool and useful, but it would be even
more cool if it could simply send a simple program for browsing a
globe and twiddling the options available (not to mention a lot
faster, fast enough to allow for things like spinning the globe.)

This is what I'm interested in; server-provided, client-executing
programs that allow a greater level of interactivity without breaking
the Web's ease of use, portability, and security. Forms that are
"smart" about what combinations of choices preclude other choices, or
can provide better feedback for users about what is and is not
appropriate entries. Animations that are dynamic and interactive, not
static MPEGs.

> > Which is already defined for Tcl. It's called Safe-Tcl.
> > It's standard, its free, its (pretty) portable, and it works today.
> > Those are pretty powerful advantages compared to "elegance".
>
>The concern I have about "safe" environments is that they often do not
>consider the interactions which can occur between machines, i.e. as

I don't know if I'd consider this a "safe" environment in that classic
sense. It's that the functionality of the language is dumbed down
from general-purpose functionality to limited-purpose functionality
that can't do anything potentially harmful.

>And I don't think that we are talking about documents that have
>built-in X11 display operations?

Sure, why not? It would tend to be better if such low-level details
tended to be abstracted away so the same program could also work under
MS-Windows or other environments, of course. A well-designed program
should tell what kind of environment it's working in (X11, MS-Windows,
with or without various extensions present, or plain text, or
whatever) and present an appropriate interface as best it can. (Tk
is, after all, already running under Windows.)

The degree to which people want to do X stuff with WWW is
considerable, as one can tell from the folks who want some
standardized way for a CGI progarm to find out what the DISPLAY of the
client is. Doing this via a program that runs on the client side
makes things a lot more efficient, interoperable, and secure.

>I haven't seen anyone advocating C or anything like it. I'm surprised
>I haven't seen anyone mention (I hope I'm not hit by lightning for
>this) Microsoft's Visual Basic.

Well, I don't know of an abstract specification for it, or a free
implementation suitable for use by developers, or a safe version of it
specified or implemented. That kind of precludes it as a serious
possibility, but not because of the langauge itself per se.

> > Yes. This is still an open question in SafeTcl, since it was primarily
> > designed for email applications. I would be interested in hearing what
> > ideas you might have on this front
>
>Ah, finally what I do want to talk about. But first, I think we
>really need to understand how smart documents will interact with one
>another or spawn one another, if they do so at all, or how cgi-scripts
>interact with other cgi-scripts, if they do so at all.

Hmmm. I guess I consider active objects to be mostly orthogonal to
CGI-scripts (or virtual documents in general.) The issue of how
multiple programs should interact with each other, if at all, is also
kind of outside the decision of what language to use as long as the
lanaguge can have whatever functionality for interaction is desired
and added.

Ousterhout is planning to integrate Safe-Tcl into the main package in
the medium-term (he was quoting a timeline of six months this summer.)
Tcl/Tk in general is a rather widely employed package, and this means
it's a a reasonable supposition that a significant number of people
will have Safe-Tcl installed on their systems within a year from now.
I know of nothing else with comperable functionality about which this
can be said.

Please don't take me as a pro-Tcl bigot. What matters to me is that I
can put active objects into anchors and have a nontrivial number of
people click on them and have it work. If others want to wait for the
Ultimate Scripting Language, OK, but the world will not.

Integrating it, or anything else, smoothly into existing WWW browsers
is another, more difficult task, since most existing clients' designs
are hostile to such integration working in any nontrivial way, but
better clients are a different issue.

Anyone think active objects should have a BOF in Chicago?

--
Marc VanHeyningen  <http://www.cs.indiana.edu/hyplan/mvanheyn.html>