OutputModules

Overview

A current problem with VisTrails is that the specification of a workflow is tied to the type of output produced. A user must, for example, produce a different version of a workflow to run a VTK pipeline that outputs in an interactive spreadsheet cell than the one used to produce a static image. In order to better support output that is execution-dependent, we propose using a generic "OutputModule" base class that other modules will subclass and define the types of outputs they can produce as well as the producedures to generate those outputs. The basic idea would be that the execution environment requests a specific output-type from the output module, and the output module returns content of that type, if available. A user could lock in a specific outupt-type (or order of preferred types) in the workflow specification if desired. Furthermore, we would allow single-session overrides (e.g. on the command-line) as well.

Objects

• OutputModule methods
  • get_output_types: returns list of support output types
  • has_output_type: returns boolean indicating whether a specific output_type is supported
  • compute_output_type: new method that does the compute given the output_type as a parameter

• OutputConfig
  • subclass of OutputModule should be paired with a subclass of OutputConfig which has any parameters for that type of output
    • e.g. SpreadsheetConfig would have CellLocation, etc.
  • Ideally, such config options would have global defaults
    • e.g. SpreadsheetConfig could have a default spreadsheet size, etc.
    • e.g. ImageConfig could have a default image type (png, jpeg, pdf)
  • the options should be possible to override for a specific session (i.e. in the temp configuration)
  • ideally, these options would have a general serialization (perhaps into the package's configuration?) that could be implemented in the base class

• OutputModule ports
  • addConfiguration: a port for any configuration---we distinguish between configurations by their output-type so a user can set configurations for file-, spreadsheet-, etc. mode outputs and the config settings for that output type will be used when running with that output enabled

Questions

• Should the spreadsheet continue to be a package? Really, the important module bits can be OutputConfig settings now.
• Thinking about implementing specific root output classes like TextOutput and ImageOutput.
  • Would also make sense to write output classes like TextFileOutput, TextStdoutOutput, etc. that specify how to output to the specific modality
  • Then, a workflow with a generic TextOutput would actually output as a specific TextFileOutput or TextStdoutOutput depending on the execution context.
  • If we change the workflow so that the execution provenance becomes easier, the version tree will look goofy and cause issues with extensions
  • If we don't change the workflow, we lose some provenance information
    • Perhaps we can workaround the provenance by writing out the configuration information about the modality used and (only) its settings?
• Should thumbnails still be generated from the spreadsheet? Should this be package dependent?
• Do we allow extensible modalities? For example, if there is not an file serialization for the VTK output, should I be able to add one without modifying the VTK package?
• How should the persistent configuration be stored (e.g. default number of rows/cols for spreadsheet)?