Notes on ParaQ and PSM Scripting

From ParaQ Wiki
Jump to navigationJump to search

Introduction
Part of designing ParaQ is codifying the value it adds to the ParaView Server Manager (PSM). One way of stating it is that ParaQ makes the capabilities of PSM available in a graphical form. We expect, however that there will be certain capabilities present in a client that are not represented in the server. This document shows some things that need to be considered in the final design.

Problematic Use Case
A user creates two windows in ParaQ, and links their timesteps. The user then creates a filter graph for each window so that it shows some relevant information. The user then wants to batch script that saved file, and iterate through timesteps, saving out an image for each window at each timestep. This use case is a problem because the user must inderstand and implement linking on his own, over the PSM. This is clearly a problem for consistency. Read on for more detail on how/why.

Linking
Linking is the process of connecting attributes of one entity to those of another, so that changes to those attributes are propogated to all linked entities. These links could be one-way, but the most useful cases seem to be two-way. For example, if two windows are linked by a camera, changing the camera position in either window will change the camera in the other window. Editing a camera directly would also produce the same results.

Assumptions

  • ParaQ will provide linking capability that will not be represented in PSM. In other words, ParaQ will be responsible for understanding linking, and for propogating the relevant data to PSM.
  • The state of the PSM represents the entire filter graph at a particular moment in time. This includes all objects, settings, and connections. This does not include any entity that performs linking.
  • ParaQ is not scriptable (except for testing purposes).
  • Scripting and batch capability is purely at the PSM level. This capability is achieved by automatic wrapping of the PSM API (see the diagram below)

    Layter diagram

Saving Data
The current design for saving state of the ParaQ application is that there will be a single xml file that includes a section that describes the state of ParaQ (including UI state), and a section that describes the state of the PSM. It is the responsibility of the PSM to proved its state for this save.

A diagrammatic example of this xml file follows:

<?xml version="1.0" encoding="ISO-8859-1" ?>
<pq:project xmlns:pq=" ... ">
  <pq:gui>
   <pq:view>
     ... view stuff
   </pq:view>
   <pq:view>
     ... view stuff
   </pq:view>
   <pq:link>
     ... link stuff
   </pq:link>
  </pq:gui>
  <psm:state xmlns:psm=" ... ">
     ... psm state
  </psm:state>
</pq:project>

The design problem comes in when we consider the interaction of scripting with the file saved by ParaQ. The PSM scripting layer will find sections of an xml file that it understands, so we expect it to be able to use the <psm:state> section of the above file. However, the link definitions, which control the behavior of the entire set of objects in the PSM state, will be ignored by the script. No linking can occur, resulting in incorrect behavior of the PSM. Users may not understand the reasons that there are differences in the ParaQ and scripting clients, and this will inevitably lead to frustration with both applications. If the PSM scripting interface is the interface for scripting, it is insufficient to support correct behavior in this case.

Conclusion
Any capability that is expected from a running a PSM-level script on a ParaQ file must be represented in the PSM. This implies that PSM must understand linking, views, and other capabilities that we had assumed would only be represented in a client.

A way of thinking about the solution to this is that ParaQ is simply another ParaView client, and it has a very limited set of special capabilities that other clients would not have.