Something like this seems like one reasonable approach.
>What we should be spending air time on is the abstract API between
>the browser and the script interpreter.
WWWinda and W3A provides places to start looking at; a restricted
interface for untrusted accessories should provide some functionality
desired. (Or should we eschew WWWinda because its implementation uses
Tcl? :-)
This, of course, requires a whole new generation of browsers; that's
fine, but means it will take quite some time and requires a lot of
consensus (is w3org involved in/interested in these sorts of issues?)
> [ list of some pretty good ideas ]
A good list, though obviously any system we create will need to be
sufficiently extensible; there will always be new good ideas. I'm not
sure exactly what you mean by "scripts can't send messages"; that
seems rather a serious limitation, though it depends what exactly you
mean by "messages."
What's more important is to support old tools, take existing tools and
try to do what we reasonably can with them, and use the lessons
learned to make better tools. That's what supporting plain text via
FTP while deploying HTML via HTTP and discussing plans for HTML+ via
HTTP/2.0 is about.
Meanwhile, advocating software and network communication protocols
that do not exist is a pointless exercise. We should do what we can
with what is here while working on what comes next; these things
complement one another.
-- Marc VanHeyningen <http://www.cs.indiana.edu/hyplan/mvanheyn.html>