> I hope the above gives you the flavour of what is required. If you
I have major concern about the such flavors as I suspect that an effort
to provide such rich function in HTML and 'generic' browsers will
destroy the middle of the road critical mass level of function we are
working so hard to achieve just getting accurate, robust support of
HTML 2 and HTML 3.
The more esoteric the function, the more difficult it will be for
publishers of 'information' to be able to expect users to have a
compatible browser. Ubiquitous availability of browsers which mostly
can cope with what is 'published' is the foundation which has led to
the explosion of interest in the Web. Its all about critical mass and
solving the majority of the problems well (and with a consistant look
and feel, at least for a given browser).
I for one will not tolerate generic code being loaded in my machine
from anywhere based on clicking of links. The security implications
are mind-boggling. Popup warnings are not sufficient for those unprepared
to evaluate the implications.
Well before we need to re-invent X I suggest we should:
a) Extend HTML forms with additional controls/wigits to cover more
of the common capabilities of basic GUI interfaces.
b) Include the ability to interactively update the current page/form
with error feed back, partial query results, etc. Pop-up
selection lists obtained from the server on demand w/wo input from
the current form.
c) Browser caching of data for reference by subsequent forms.
d) Send more time on specification of rendering behaviors to improve
common look and feel between browsers.
e) Support for power-keys. I should be able to drive a browser without
having my hands leave the keyboard...
f) Better integration of component code then the current generation
'helper' routines for audio, video. Some careful work in the area
of extensible HTML entities or whatever to allow access to unique
features of a particular browser. We must assume that not all browsers
will handle all features of future versions of HTML. What is needed
is an architecure which allows a browser to know the impact of its
inability to handle a new feature in the data stream. For example,
an input control which wasn't understood should probably preclude
submission from a form containing it. At moment, the approach is
mostly ignore what you don't understand and our design discussions
have focused on what happens if something is ignored. I'm suggesting
that we need a more sophisticated mechanism for negotiating the
quality of rendering vs. impact on the application.
Beyond this, the question at this point needs to be the capabilities of
browser scriptability not the language or implementation. Tcl, perl, rexx,
a new vm, VBasic, Citrix remote NT protcols, X client / server protocols,
etc. are all possible ways to represent remote control over the user's
interface but I think discussions about the implementation(s) now before
we have a careful set of objectives is putting the cart before horse.
The capability matrix might factor in trustworthyness of the source of
the 'code' -- if there is a need for function which might compromise
the security of the user's environment.
I've ranted long enough.
Dave Morris