Re: Local program exection in WWW browsers

Stan Letovsky <letovsky-stan@CS.YALE.EDU>
Errors-To: listmaster@www0.cern.ch
Date: Wed, 13 Apr 1994 16:29:23 --100
Message-id: <199404131423.AA19985@RA.DEPT.CS.YALE.EDU>
Errors-To: listmaster@www0.cern.ch
Reply-To: letovsky-stan@CS.YALE.EDU
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: Stan Letovsky <letovsky-stan@CS.YALE.EDU>
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: Local program exection in WWW browsers 
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Length: 2014

Subject: Re: Local program exection in WWW browsers
From:    gra@zeppo-sa.East.Sun.COM (Gary Adams - Sun Microsystems Labs BOS)
Date:    Wed, 13 Apr 94 09:58:54 +0400
To:      www-talk@www0.cern.ch, letovsky-stan
---------
>
>> [Letovsky]
>> 
>> 	I think what is needed is a scripting language extension to
>> HTML that allows programs to manipulate the browser state, including
>> possibly dynamic restructuring of the displayed documents. Dave Raggett
>> is including an API for such languages in the HTML+ spec. Security concerns
>> can be addressed by restricting the operations available in the language --
>> e.g. no file system manipulations, or only interactively confirmed ones.
> [Adams]
>Would Telescript or Safe-Tcl be viable candidates as embeddable control
>languages in HTML docs? I don't know a lot about these languages, but 
>it might save a lot of development time to leverage an existing body
>of code if it meets the need. 
>
[Letovsky]
I thought the reason for implementing the language extension as an API
is to facilitate using any language as the scripting language...  but
the more I think about this, the confuseder I get.  (Dave -- feel free
to jump in here any time!)  I thought an API specifies a library of functions
that can be called by an application -- but what application? If we
are manipulating the browser state then the application must be the
browser, no?  Which means it must have an interpreter for the
scripting language in it, no? So you are providing both an API and a
hole in which to put a language interpreter, plus a syntax for
embedding scripts in HTML?  If this is the model, my biggest concern
is that by encouraging proliferation of scripting languages you will
be creating a Babel of browser/script-containing-document
incompatibilities.  Better to choose a language: one of the above
mentioned, or others -- a safe subset of perl or emacs lisp are other
possibilities -- any choice will be controversial, but no choice seems
worse!??!

Sign me,

	Confused