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).

As mentioned above, there will be two ParaQ clients:

• Qt client
• Python client

Both will access the VTK layer through the server manager. Note that these are two separate applications. We do not plan to include a python interpreter in the Qt client. However, the python client should be able to connect to the server through sockets at the same time as the Qt client. This means both will be able to drive the same session simultaneously.

Note: When either client is running in standalone mode, the same process will be client and server at the same time. In theory, the other client should be able to connect to this process and issue SM command. Most probably, this will not be possible if the main process is the python client (i.e. python client is started first and is driving the server). Since python does not provide an event loop, it cannot listen to a socket and provide a user prompt.