...
Rather than a single repository view, this might actually will probably be multiple views that are configured to show a particular type of data using a coming from a content provider. The content provider that gets would get the data type required from the tupelo contexts it knows aboutconfigured tupelo context(s). For example, we might have something like will need a "Data Repository View" that shows all datasets (e.g. input/output datasets) and a way to manipulate them (e.g. add tags, annotations, etc), "Scenario Repository View" that shows all defined saved scenarios, "Service Repository View" that shows defined RMI service endpoints for launching jobs, etcand a "Known Hosts View" for showing known hosts that can accept jobs. This seems like too much disparate information to display in a single view.
A repository is anything that is In SAGE and all derived products, a repository is going to be used for storing information that must be persisted and includes input data, output data, saved scenarios, and beans that describe thingsworkflows, etc.
Functional Requirements
- Import datasets that will be used as input to HPC workflows such as Mesh files, input files (e.g. mach number, poisson ratio, etc)
- Store output datasets
- Store scenarios
- Store defined RMI services
- Store known-hosts
- Store workflow xml files (Ogrescript)
- Other functionality?
...