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