Persistence of script data
Problem Statement:
Scripts may wish to store state in a document. We need to define the mechanisms
that scripts will use to store persistent state. This will describe what
types of data the script can store, where the data gets stored, and how the
script loads and stores the data from persistent storage.
Use Cases:
- User may run a script that needs to store data for use the next time it
runs
- User might want to change a stored value before running a script
- Developer might want to specify a default value for a stateful variable
- Developer may write multiple scripts which depend on one shared value
Analysis:
Where do we want to store it?
We need to work out where script data is stored relative to the script. The
context of the script is also important here (application or document level).
1. Do not prescribe the storage location, scripts persist their data wherever
they want.
2. Script manager controls the storage location.
3. Each script engine controls the storage location for its language.
Suggested solution: 2 - scripts should not store data in arbitrary locations, or in a language specific way, we should provide a centralised script data persistence service in the script manager
Where does the script manager store the data?
Assuming that the script manager will manage the physical storage of script
data, we need to define where it would store it.
1. Store scripts and data in the same file. The script source code and the
data for that script could be stored in seperate xml tags within the file.
2. Store it in a seperate file within the document zip file. This would make
it harder to manage the script files especially for documents with multiple
scripts attached. However, it would make it easier to access the persisted
data outside of the scripting framework, for example, if running the script
from the command line.
Suggested solution: 1 - if the xml format is defined then it should be easy
to access the script state within the file.
What are the APIs scripts use for loading/storing persisted data?
When executing a script, script engines will have access to the stored data
for that script via the script manager. We need to define the API that the
script engine will provide to the scripts for obtaining this data.
1. script managed persistence - load/store as strings
Pass the stored data as parameters to a method invocation. This would require
that data be stored as strings and that the script would convert the strings
to an appropriate type. The script engine could also provide methods to load/store
the script state:
String[] loadState()
storeState(String[] values)
It may make sense to store the values as name/value pairs so they don't have
to be loaded/stored in a particular order.
2. script managed persistence - load/store to a stream
Provide a stream based API for loading and storing the persisted state:
InputStream loadState()
storeState(OutputStream)
The script can obtain the script data storage interface from the script engine
and initialize variables using values obtained from the input stream or store
them to the output stream.
3. engine/container managed persistence
Provide serialization mechanisms for persistence of arbitrary datatypes.
The script engine initialises variables in the script with the stored values.
While this model is already supported in Java, it could be very difficult
to implement such a model in some languages.
Suggested solution: 1 - a string based interface would be easier to implement
in most languages
What types of data do we want to store?
We need to investigate what values a script developer might want to put into
persistent storage to be reloaded the next time that a script runs. This
choice will influence the persistence API we define.
1. Limit the type of data that can be stored to strings. Scripts can only
store string values which they must convert back to the correct type when
reloading.
2. Allow scripts to store any data type, including objects.
Suggested solution: 1