This topic is prompted by a recent, broader discussion about implementing a save-as functionality with the new smtk::project code (which is not yet merged into smtk:master). But before discussing projects, I think we need to first clarify what save-as behavior should be for baseline SMTK resources.
When the modelbuilder “Save As” menu item in invoked, the current software writes the selected resource to a new location on the local file system. That resource is identical to the original in terms of the UUIDS used to identify the resource and its components. This leaves two copies of the same resource on the disk. If either is modified in modelbuilder or otherwise, the result will be two resources with the same UUIDs but different contents. Just to be clear, that’s not what we want.
The two .smtk files themselves are not always identical because resource contents are not always written in the same order.
If a user then tries to open two .smtk files with the same resource UUID into modelbuilder, my understanding is that the second “open” will be ignored by the application because a resource with the same UUID is already loaded.
We went to some effort to support the copying of a resource by copying the .smtk file and any native/auxiliary files that go with it. Although that is a very useful feature for internal development, I don’t consider it mandatory to support this as a long-term requirement.
The basic requirement is to duplicate a resource so that the copy has the same external behavior as the original but is a distinct/different smtk resource.
The implementation is envisioned as an in-memory operation analogous to the document save-as feature in applications such as Google Docs. The copy of the resource is serialized to a new location in the file system and, from the end-user’s perspective, the original resource is removed from memory and replaced by the copy.
In terms of resource links, my opinion is that associations of the copy should track the original. For example, if an attribute resource is associated to a model resource, then a copy of the attribute resource should also be associated to the same model resource and the copy’s component associations should behave the same as the original’s.
In contrast, because associations are not symmetric, a copy of the model resource in the same example is not associated to the original attribute resource.
Whether or not the attribute resource’s associations can be readily “switched” from the original model resource to a copy of the model resource isn’t an immediate requirement, but will be needed when the scope of this discussion expands to include SMTK projects.
In a similar way, if a mesh resource is classified on a model resource, then a copy of the mesh resource should also be classified on the (same) model resource. But a copy of a model resource has no relation to meshes classified on the original model, though there is motivation to reclassify mesh resources onto copies of the model resource.
The two approaches discussed most are:
1. Create the copy of the resource with a new UUID, making the original and copy different resources with no direct relation between them. Both can be loaded into modelbuilder and used independently. This would mimic the document save-as paradigm.
2. Add a “version tag” to the smtk::resource::Resource class and update it each time the resource is written to disk. Conceptually, the original and copy would be variants of one resource and the version tag (alternate name suggestions are invited) would provide an initial resource provenance capability.
The version tag could be implemented as a UUID (perhaps one based on date-time?)
The resource could potentially store an ordered list of version tags to reflect the history of changes.
I think that SMTK would support loading multiple variants of the same resource, perhaps with only one being editable and the others available for view/comparison?
Both cases require TBD updates to the SMTK resource manager.