What we should be spending air time on is the abstract API between
the browser and the script interpreter. Trusted scripts can be recognised
as such as they will carry a digital signature plus certificates in the
HTTP header. I will therefore concentrate on untrusted scripts:
o scripts can read a set of browser environment variables
e.g. the user's name, email address, time of day etc.
o scripts can read the contents of form fields and their
associated status flags (in-error, disabled).
o scripts can set the contents of form fields and their
associated status flags (in-error, disabled).
o scripts can get/set the current focus
o scripts are passed various classes of events, e.g.
get/release focus, mouse clicks, keyboard events
o scripts can set/clear a system error message
o scripts can access a few well chosen library routines
o scripts are limited in the amount of memory or screen
resources they can consume
o scripts interpreters are linked to the browser via
a (scripting) language independent API
o form fields belong to a well defined set of classes
but there is a way to define new classes that are
painted by the script
o scripts can't send messages
I don't have time to refine this, and would love to see other people
work together on refining this into a detailed proposal, rather than
arguing on which language to choose.
p.s. why not Visual Basic :)
-- Best wishes,Dave Raggett
----------------------------------------------------------------------------- Hewlett Packard Laboratories email: dsr@hplb.hpl.hp.com Filton Road tel: +44 272 228046 Stoke Gifford fax: +44 272 228003 Bristol BS12 6QZ United Kingdom