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:

• Thread management
• Persistence of script data
• Symbol/Dependency Resolution

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:

• Code management
  

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:

• IDE requirements
  

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