Good question! So far I can think of two main types of workflows we are interested in modeling, Procedural-Driven Workflows (PDWF) and Resource-Driven (RDWF). A Procedural-Driven WF is the more typical I think in that it is a sequence of operations (like a recipe) that need to be performed. For example a Point Cloud-based workflow could be:
Load Point Cloud File
Create Area of Interest
Extract Surface Point Cloud
Convert and Save as DEM
Another example could be processing something like creating a model from DEM data in SceneBuilder:
Load in DEM
Perform contour extraction
Remove unwanted edges
Add new edges to close loops
Create Model Faces from extracted edges
The Resource (or Data)-Driven WF is a sequence of “conceptual” stages. In order to advance to the next stage resources with certain characteristics must be present. For example the above two workflows could be combined as follows:
Create appropriate DEM model
Define model edges
Define model faces
To move from step 1 to 2 requires a DEM model to exist. It could have been loaded directly into the system or created by loading in a point cloud and processing it. To move from 2 to 3 the condition could be that a model must exists and contains at least one model edge or perhaps the condition is that all of the model edges form a closed loop network.
In a RDWF there may be a bunch of tools that the user could use to meet the requirements of a particular stage. For example, in Define model edges the user could explicitly draw the edges or use tools to extract them. In the PDWF, the process is more rigorous.
Note that a real workflow could have aspects of both PDWF and RDWF.
There is a third type of loosely defined workflow which I refer to as Skin Workflow. Think of a Skin as an "open-ended" workflow were the designer is defining more of an application as oppose to a specific workflow. For example, the current CMB applications could be thought of as a set of Skins being used by a single application.
Workflows versus Views
SMTK Views provide a mechanism of visualizing and interacting with SMTK Resources and Operations. They determine how a model is displayed, what parameters an operation requires, and how an attribute can be edited. You could say that the current attribute tab could represent a workflow stage called “Assign Attributes” (which could lead you to think that the very top UI widget in CMB is sort of the workflow and perhaps it should be). But the Views themselves do not represent a workflow.
Anatomy of a Workflow
A Workflow could involved the following components:
Plugins (for additional functionality and Sessions)
Actions that could be used in menus, palettes and toolbars
Instructional Text Area to guide the user
Asynchronous Operator Management Panel
Reporting current status of active processes
Ability to cancel an active process
Set of Tasks
Pedigree/revision tracking/tagging so that people can sign off on changes
Everything defined at the Workflow level with the exception of Tasks are available to all of the Workflow’s Tasks.
Declarative vs. Programmable Workflow Specification
There is a strong motivation to have workflows be specified in a declarative manner such as through a file. It would be easy to modified and would give rise to a workflow editor application. At the same time one can image complexed workflows involving branching and looping sub-workflows with complex completion conditions. In these cases, having a programmatic option will be essential. In terms of language support, probably Python would be the best choice due to its wide spread acceptance as a "Glue" language. Ideally one can imagine a hybridization of the two approaches. For example a declarative specification that includes Python sub-sections.
In addition, it should be possible to have developers create their own workflow executive process that could then be used in a CMB application.
Represents a stage in a workflow and could consist of the following:
Its own set of Views, Menus, Toolbars, Palettes, and Actions
Setting the state of available actions (either on or off) as well as hiding them
Task Activate Condition - when can this task become active
Task Completion Condition - when can we consider this task completed
In this case an Action is very similar to a Qt Action with the exception that it should not be forced to be derived from the Qt class. The reason for this requirement is to allow for the possibility of web-based applications supporting the same workflow input. In terms of functionality an Action would have the following:
Enabled/Disabled (similar to Qt Action)
Enabling Condition (what enables this action?)
Active - is the action currently being executed
Synchronous or Asynchronous
Completion Status (OK, Error, Canceled, etc..)
Brief and Detailed Descriptions
In terms of Action Types, these would include:
SMTK Model Session Operations
RemUs Meshing/External Operations/Workers
Command Line Functions
The one main question is what is being passed in with respect the canBeEnabled and execute methods. It should be related to the state of the CMB application including:
What is currently selected
Model Entities / Resources
Mesh Entities / Resources
Attributes / Resources
What resources are available in the state?
What interactors are available (or can be added) to the application?
Actions can then be mapped into the appropriate GUI based on the type of application (for example Qt in the case of a Desktop App)
How can the designer reuse parts of a workflow to create new workflows?
How can we add command-line driven tasks to workflow (without having to define a some kind of Session)?
How to refer to a Session’s operator when defining an action?
Comments 13-Oct-2015 (john)
1. I think we should make a more precise distinction between workflows, tools, and data/resources. A workflow, regardless of its "type" (resource-driven, procedure-driven, open-ended), is a set of activities designed to produce one or more data entities or resources (I mean “resources” in the generic, non-smtk sense of the word).
Activities are typically performed (or, at a minimum, initiated) by human users.
Activities typically require certain resources (input) and modify those resources and/or produce other/new resources (output).
Activities can be decomposed into sub-activities, so that workflows of arbitrary complexity can be defined (although Kitware's implementation may defer this feature).
Activities are typically carried out with software tools/applications, such as those in the CMB suite. Leaf level activities preferably require only one software application
Comparing CMB workflows with home construction:
blueprints, specifications, checklists
input data files, models, simulation files, etc.
lumber, sheetrock, concrete, shingles, etc.
saws, nail guns, screw drivers, shovels, etc.
2. In terms of declarative vs. procedural specification, I advocate starting with a declarative approach. We could try to adapt cmake's syntax -- or, better still, webpack, grunt, or bower -- however, I am not sure how well any of these can represent human-driven workflows. Whatever the case, I recommend we try codifying a feature set for each CMB tool, that is, come up with a set of activities each supports as well as the resources each activity consumes and modifies/produces.
3. In terms of tracking progress for a given workflow, I think this should be based on the resources that have been modified/produced. Users should be able to "commit" a given resource to a baseline data store as part of completing an activity. The workflow system should also allow users to store resources that are partially complete, experimental, or otherwise works in progress, but not part of the baseline; ideally, users could attach text or other meta data that they can use to easily find the resource later, or remember who saved it and why. And, of course, users should be able to update a resource in the baseline, or remove it entirely. This could impact downstream resources, but more thinking is required here.
4. I can envision cases where the workflow system should support some kind of resource tagging. This might apply to the previous case, where a resource is tagged to indicate one or more of its upstream resources has changed. Another example might be if a resource requires some kind of review or sign off. In that case, the resource contents might not change at all, but the workflow should be able distinguish between the reviewed and un-reviewed cases.
5. Regarding the second question about adding command-line driven tasks to a workflow, I would say absolutely YES: Our workflow system must be able to support activities that are performed with tools outside the CMB suite.