Scripting Framework Problem Areas & High-Level Issues
Runtime Container
Problem Statement:
Scripts are executed within a language specific script runtime. We need
to define the features of this runtime container and the contract between
the container and the scripts run in it, with regard to threading, symbol
resolution and persistence of script related data.
Requirements:
- define the contract between the script container and a script, this
contract should be language neutral
- define the threading model that script containers should use
- define how symbols are resolved within the script container
- define how symbols conflicts are handled
- define the services the container provides to the script for saving
state
Issues:
- the requirement for language neutrality will impose restrictions on
how the contract between the script runtime container and scripts run
in the container can be defined
- it would be impossible evaluate our contract against all scripting
languages, so we must select a subset of languages to use
Further analysis:
Code Management
Problem Statement:
Scripts can be in many formats, source or binary, encrypted or obfuscated.
They can be stored in many locations, eg. a filesystem or a webserver.
They can be stored as files, or embedded within a file. They can be protected
by security features such as digital signing.
Clients of the scripting framework (eg. StarOffice, IDEs) need to be able
to access these scripts without concerning themselves with where and how
the scripts are stored. The Application Scripting Framework needs to provide
a set of services and interfaces which will allow these clients such access.
Requirements:
- research current StarOffice script location/load/store interfaces
- define the digital signing service for scripts
- define the script location service
- define the script loading/storing service
Further analysis:
IDE related Issues
- Do we want a scripting IDE as part of SO (I will call this internal
IDE for simplicity) or an external one plugging into SO? One option could
be to have an internal IDE for StarBasic and an external IDE for the new
scripting languages. The external editor should be NetBeans (Forte for JAVA?).
NetBeans already has some support for BeanShell, Dynamic Java and Jython.
This support definitely needs further improvements. If we go with NetBeans
then we might need to cooperate with NetBeans developers. NetBeans has a
framework for plugging in new scripting interpreters into the IDE.
- The main issues are debugging and editing scripts, code browsing,
configuration.
- We need possibilities to edit and debug scripts from simple command
line applications.
Code editing:
We need the script storage and script loading and storing interfaces
as described above. This needs to be able to retrieve and store a script
source and its context (document, application). Both the IDE (internal and
external) and the command line application need to use these interfaces to
edit scripts and their contexts.
NetBeans has an API that abstracts storage of files and file like objects.
This could use the script loading and storing interfaces to edit scripts.
Context editing could be done with Nodes, the DataSystems API and the Explorer
API, but this needs to be investigated.
Debugging:
Main issues are launching, setting breakpoints and evaluating variables.
The IDE has to be able to launch the language specific debugger/interpreter
and load the binary/script source and its context in it, an interface has
to be defined for this.
OpenOffice already has an interface
for setting/clearing breakpoints and evaluating variables. This could be
the interface the debugger/interpreter plug-in of a new language will have
to implement. An IDE will have to use this interface to implement the debugging
tasks and implement a Watch and Output windows to display various information.
(If we go with NetBeans) the JVM and NetBeans are already integrated and
they do not use this interface so without a language agnostic framework
most of the work would be done. If we want a language agnostic framework
we will have to add extra implementation for languages not supported by NetBeans.
This would be different from the way the JVM is integrated.
If we go with one or more Java based scripting language(s) as part of our
implementation then we need to investigate ways of translating script code
line numbers to Java code line numbers and script variables to underlying
Java variables. Command line debugging does not need much here, the user
will have to launch the language specific debugger and configure it (to
find the SO libraries). A command line utility will need to be developed
that will load the script in the debugger/interpreter and make it aware
of the script context.
Code browsing:
This is not as important as the previous ones.
We need an interface that would return object and method names from a script.
This will need language specific implementations. The IDE will have to
use this to display and navigate through the code structure.
There would be no command line functionality here.
Configuration:
This has already been described as "runtime-related user interfaces". We
need a way to provide similar functionality when debugging from the command
line.
Further analysis:
Macro Recording
Macro recording is not a very big issue in the investigation phase. The
main issue is whether we can generate macros made of UNO API calls or we
have to stay with the dispatch APIs. The investigation should be about
whether this is possible or not and how to do it. It is very simple to
write macro recorders for any language if the recorded macros use the dispatch
API. Considering that for UNO API based macro recording we would probably
have to write UNO API based macros for all the dispatch calls in all the
languages that we support, UNO API based macro recording might not be feasible.
But this should be the subject of the investigation.
Runtime related security
Problem domain definition:
The language runtime security subsystem is a set of restrictions which
are applied by the language runtime to a script during loading and execution.
Restrictions could be applied to:
- the type of the script
- the source of the script
- the length of life of the script
- the amount of resource available to the script
- the availability of a service by the type of the service
- the availability of the specific service by the type of the
request
- the availability of the specific service by the content of the request
Participants:
- the script execution sandbox
an implementation of the language neutral runtime security subsystem
- the language runtime (the runtime container)
language specific binding to the execution engine (VM)
- the language execution context
static and runtime data available to a script during execution
- the code management subsystem
script finder/explorer/loader
- UI of security configuration
- debugger
Script lifecycle services
Problem domain definition:
The script lifecycle services is a subsystem of the execution engine (VM)
which is responsible for:
- creation and maintains of the script execution context
- control over the script length of life
- accounting of the script acquired resources
- clean up after the script end of life.
Participants:
- the code management subsystem
script finder/explorer/loader
- the language runtime (the runtime container)
language specific binding to the execution engine (VM)
- the language execution context
static and runtime data available to a script during execution