OutputModules - Revision history

Remi at 16:02, 9 April 2014

2014-04-09T16:02:30Z

← Older revision		Revision as of 16:02, 9 April 2014
Line 1:		Line 1:
	== Overview ==		== 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.		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 procedures 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 output-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 ==		== Objects ==

Dakoop: /* Questions */

2013-08-14T00:22:27Z

Questions

← Older revision		Revision as of 00:22, 14 August 2013
Line 31:		Line 31:
	*** Perhaps we can workaround the provenance by writing out the configuration information about the modality used and (only) its settings?		*** 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?		* 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)?

Dakoop: /* Objects */

2013-08-14T00:19:19Z

Objects

← Older revision		Revision as of 00:19, 14 August 2013
Line 15:		Line 15:
	** Ideally, such config options would have global defaults		** Ideally, such config options would have global defaults
	*** e.g. SpreadsheetConfig could have a default spreadsheet size, etc.		*** e.g. SpreadsheetConfig could have a default spreadsheet size, etc.
	*** e.g. ImageConfig ~~coudl~~ have a default image type (png, jpeg, pdf)		*** 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)		** 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		** ideally, these options would have a general serialization (perhaps into the package's configuration?) that could be implemented in the base class

Dakoop at 00:19, 14 August 2013

2013-08-14T00:19:04Z

← Older revision		Revision as of 00:19, 14 August 2013
Line 11:		Line 11:

	* OutputConfig		* OutputConfig
	** subclass of OutputModule should be paired with a subclass of ~~OutputConfiguration~~ which has any parameters for that type of output		** 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.		*** e.g. SpreadsheetConfig would have CellLocation, etc.
	** Ideally, such config options would have global defaults		** Ideally, such config options would have global defaults
	*** e.g. SpreadsheetConfig ~~has~~ a default spreadsheet size, etc.		*** e.g. SpreadsheetConfig could have a default spreadsheet size, etc.
	*** e.g. ImageConfig ~~has~~ a default image type (png, jpeg, pdf)		*** e.g. ImageConfig coudl 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)		** 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		** ideally, these options would have a general serialization (perhaps into the package's configuration?) that could be implemented in the base class
Line 24:		Line 24:
	== Questions ==		== Questions ==
	* Should the spreadsheet continue to be a package? Really, the important module bits can be OutputConfig settings now.		* 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?		* Should thumbnails still be generated from the spreadsheet? Should this be package dependent?

Dakoop: Created page with '== 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 ve…'

2013-08-13T00:49:56Z

Created page with '== 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 ve…'

New page

== 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 OutputConfiguration 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 has a default spreadsheet size, etc.
*** e.g. ImageConfig has 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.
* Should thumbnails still be generated from the spreadsheet? Should this be package dependent?