ParaQ:Scripting

Requirements

ParaQ scripting requirements can be found here

Design

ParaQ scripting will be build on top of the server manager (SM) API. Main reasons behind this decision are:

• We need a scripting interface independent of the GUI (accessible through the python client)
• SM is designed to provide such an interface
• SM is already wrapped into Tcl, Python and client/server streams

ParaQ scripts will directly manipulate the SM through it's published API using one or more of the supported scripting languages (Python, Tcl and Java). A python client will be implemented (more on this later). In order to provide a easy-to-use, full featured and backwards compatible scripting language, the following guidelines will be followed:

• Clean separation of GUI/engine functionality. All the functionality to be accessed through the scripting interfaceshould be implemented in SM and accesses through the publish SM API by the GUI.
• Stable SM API. Since the scripting interface will depend on the SM interface, SM API should be stable and backwards compatible as much as possible. If possible, backwards compatibility should be automatically tested routinely.
• Clear and easy-to-use API. The SM API should be clear. Although the SM API is verbose due to it's design, simplifications can be made in the scripting language.
• Well documented. Wherever possible, documentation should be automatically generated from the code (a la doxygen and more). Where automatically generating the documentation is not possible, it should be hand generated.

Implementation details

ParaQ will be able to save the SM state in two formats:

• XML
• Python scripts

Both will be generated from the in-memory representation of the state (stored as XML nodes) by either directly saving or parsing/converting. This will ensure that the code to save state is centralized and both are always in sync. Users will be able to edit and load both back into ParaQ (XML into both GUI and script clients, python into script client alone).