Proposed Plan for Project Support (Draft)
A SMTK project represents an instanced simulation workflow. It simplifies the loading and saving of a workflow by treating all of the necessary resources (and operations) atomically.
In a non-project workflow, the user is responsible for loading all of the resources (including the instantiation of attribute template files) required to implement the workflow. The user is also responsible for explicitly saving those resources and tracking them on disk.
In the case of a project workflow, a project is created via a template or operation. Relevant attribute templates are instantiated automatically when needed. Any resource required by the project but not automatically generated is presented to the user as a requirement to be fulfilled or assigned during project creation. When a project is saved all required resources are saved atomically and in a known location as part of the project. Conversely loading a project also loads in all of the project’s resources (or at least loads them into the resource manager to be loaded in later (this feature of the resource manager is not yet implemented)).
- Ability to be used in operations as well as be returned as a result.
- Ability to create a project for a specific type of workflow either using a template or using a operation.
- Ability to define new types of projects at runtime - this will allow new project types to be created using Python operations as well as using a file-based specification.
- Ability to refer to a collection of resources and associated a “role” which respect to them.
- Ability to contain project specific information not contained in any of the resources it is linked to.
- Ability to specify either a white or black list of operations required by the project
- Ability to specify the list of SMTK Plugins required by the project (as well as their version)
- Support both a conceptual version identifier for its meta data and an user version identify for the information contained within the project
- Projects should contain the following:
- Name (non-unique)
- Type (unique string)
- ID (unique)
- Visualization/ParaView State (TBD)
- Ability to hold a Workflow (TBD)
- The ability to model other simulation assets such as simulation input decks and results. In theory these could be modeled as other resources (or components) so they could be used in operations, associated or referred by attributes. (TBD)
- Ability to hold post processing information such as xml representations of ParaView pipelines.
- Projects should be relocatable within the user’s filesystem and packable if being moved to a different machine.
- A project should describe how its required resources are named/saved to disk.
- Ability to embed a change log into the project. When the project gets saved the user should be prompted for a reason for the modification. If specified it should be saved along with the rest of the information (ideally along with the current date/time).
Possible Design - Deriving from Resource
After discussing it with other developers it sounds like Project should be modeled as a new kind of SMTK Resource. This will have the additional benefit of satisfying many of the above requirements with little additional code.
- Projects could be easily incorporated into the GUI (for example you could show a Project within a Resource Browser as well as its related resources.
- Name (string)
- Type (string that is set on creation)
- ID (uuid that is assigned on creation)
- Location of Project Directory (set when reading or doing a save as)
- Conceptual Version (assigned when a project is created) - this identifies the version of the meta-data used to create the project and its required resources
- Project Version - assigned when the project is saved
- Internal Attribute Resource for Project Specifics (#4 & #5) - this would also simplify GUI support for projects since its internal attributes could be easily rendered.
Add Project Item and Project Item Definition to Attribute Resource
This is required to satisfy 1 & 2. Project Item Definitions should include the type in order to restrict which projects can be referenced by a Project Item as well as the corresponding Qt classes.
What is the state of a project?
Currently a project’s state would include the information on the project itself as well as the state of the project’s resources.
Similar to the Resource Manager, the Project Manager allows the registration of new project types and provides the following functionality:
- Construction of new projects of a specified type
- Ability to read in an existing project
- Ability to import into a new project
- Ability to write a project
- Makes sure the required plugins are loading when creating/loading a project
- List of Operations required (or not required) (tags? categories?)
- Creation of autogenerated resources (like templated attribute resources)
- Required Input from user -> if using a Project creation operation
- Customization of UI
File System Structure
- Projects are represented by a directory (or as a zip archive of a directory) and have a .smtk extension
- A project directory should have a project.smtk file to indicate that it is a SMTK Project directory. The file contains all project related information including its internal attribute resource as well as File Version indicating the format of the project file.
- A project should indicate how it wishes to deal with existing resources or native model files. The options could include:
- Relocate both SMTK and/or native files into the project directory
- Relocate only the SMTK file into the project directory
Originally I had a move neither option but if a Project sets properties on the resources to indicate their role in the workflow then you would at least always need to write out the SMTK resource.