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
Use Cases:
- User wants to see a list of all scripts that are available to run,
or bind to an event.
- User wants to see a list of all scripts that support a particular language.
- User wants to see a list of all scripts that display a particular property
eg. all scripts stored as source, all scripts that are signed.
- User wants to be know if a script performs certain functions that may
be insecure eg. file i/o, executing other programs.
- User wants to be warned if a script has changed since it was loaded
into memory.
- User wants to save a document level script to application level storage.
- User wants to delete a script.
- User wants to run an encrypted script.
- User wants to run a script that has been signed.
- Developer wants to edit a script within a text editor
- Developer wants to edit a script within an IDE
- Developer wants to sign their script so users can verify its authenticity
and integrity.
- Developer wants to package a number of files together which are all
part of one script.
- Developer wants to package a number of scripts, each of which depend
on some shared files and some files which are unique to each script
- Developer wants to package a binary version of their script
- Developer wants to ship an encrypted version of their script which
can be run without entering a password, but can only be unencrypted and viewed
as source by entering the password
- Developer wants to specify the encryption technology for their script
- Administrator wants to deploy a script on the network for use by many
clients
- Service Provider wants to deploy a script on a website for download
Research:
What are the current StarOffice script location/load/store interfaces?
At installation, application level StarBasic scripts are stored in the StarOffice
installation directory under the paths:
<installation dir>/share/basic;<installation dir>/user/basic
StarOffice looks for StarBasic scripts in the directories specified in the
"Basic" property which can be modified in the Tools/Options dialog under
StarOffice/Paths. By default this property is set to the two directories
above.
Document level StarBasic scripts are stored in a directory called Basic within
the document zip file, ie. <doc root>/Basic/*.
Library names and properties associated with libraries are stored in an xml
file, script.xlc for application level, script-lc.xml for document level.
The DTD for these files is libraries.dtd.
The information about modules within the library is stored in another xml
file, script.xlb for application level, script-lb.xml for document level,
with the the DTD defined in library.dtd.
Location/Load/Store of StarBasic libraries and modules is done by the BasicManager
class via implementations of the XLibraryContainer and XNameAccess UNO interfaces.
Analysis:
What are the application and document level default locations for scripts?
1. For backwards compatibility, keep the directories used by StarBasic and
create new directories for each language supported eg. java scripts would
be stored in:
<installation dir>/share/java;<installation dir>/user/java
Similarly document specific scripts would go in a language specific directory
within the document zip file, ie. <doc root>/java/*
2. Replace the basic directory with a "scripts" directory, install all scripts
in this directory regardless of language.
3. Replace the basic directory with a "scripts" directory and create a subdirectory
for each language when installing the script engine for that language.
Suggested solution: 3
How do we locate scripts?
We can only search for scripts in well known locations, or in locations that
have been specified by the user initiating the search.
1. Use a setting like the "Basic" setting in Tools/Options which points to
the default application level scripts directories, eg.
<installation dir>/share/scripts;<installation dir>/user/scripts
2. Provide an API to set/get the script manager search path programmatically
3. Provide an API that allows for searching a specific search path, or set
of paths, some of which may be URLs.
Vector findScripts(String[] path)
4. Provide an API that allows for searching for all scripts with a particular
property
Vector findScripts(Property prop)
5. Implement a script registry, scripts are registered at install time and
the find APIs query the registry not the filesystem.
Suggested solution: 1, 3, 4 (and maybe 2)
What is the format of a scripts deployment descriptor?
Scripts when deployed will need a deployment descriptor which allows a client
to get the properties of the script without having to access all of the its
files.
1. Define a common deployment descriptor for all languages based on the current
definitions in the http://openoffice.org/2000/library namespace.
2. Allow for language specific script information (eg. language specific
encryption information) to also be stored in the deployment descriptor which
is passed on to the script engine.
Suggested solution: 1, 2
Where is the deployment descriptor stored in relation to the rest of the
scripts files?
If searching by property, the find APIs may need to search for deployment
descriptors, so if for example, the deployment descriptor is stored as part
of a jar file, the find API will need to know that it should search within
jar files.
1. Specify that deployment descriptors can only be deployed within the language
specific scripts directory, not embedded within another file such as a jar.
2. Have each script engine implement a find API. The script manager find()
invokes the find() for all of its script engines.
Suggested solution: 2
How do clients that do not use script manager locate/load/store scripts?
Clients such as IDEs may not wish to start a script manager in order to locate/load/store
scripts.
How do we handle changes to scripts already loaded?
The user may invoke a script which has changed since it was loaded by the
script engine.
1. Do not load scripts into memory in the script engine, the script manager
passes a stream to the script engine from which it reads when running scripts.
2. Have script engine register a callback which is invoked when script is
changed. It can then reload the script into memory. The editor of the script
(IDE) could invoke the callback, or the script manager could monitor for
changes to scripts.
3. Have the script manager keep a record of all scripts currently loaded
by script engines. When the script manager receives a request to execute
a script it checks if the scripts has changed since it was loaded to the
script engine and asks the user if it should be reloaded if it has.
Suggested solution: 3
How does the encryption/decryption service work?
1. Do not provide encryption support directly, just pass the script to the
script engine and let it deal with the problem.
2. Provide a default encryption implementation (StarOffice already has one)
in the script manager and allow for integration of other encryption technologies.
Provide an interface to get/set encryption service, and to invoke it.
setEncryptionService(String name)
boolean encrypt(InputStream in,
OutputStream out)
boolean decrypt(InputStream in,
OuptutStream out)
Suggested solution: 2
What is the digital signing service for scripts?
1. Do not support code signing, script engines can handle signing if they
wish.
2. Provide a signing mechanism. Investigate Java applet signing.
Suggested solution: 2