Although I signed off on SMTK MR 1429 (“Save attributes as json files”) yesterday, I don’t really like where we ended up with filename/extensions, and I presume no one else does either. I would like to propose an alternative going forward. My biggest concern is still that modifying the specified filename under the hood doesn’t seem like the least astonishing of our alternatives.
Because I have that fool’s advantage of not understanding the resource system internals, I am making some speculations about how things work. So I welcome any corrections or clarifications as well as general feedback.
1. In the smtkCore library, if the resource READ operators truly do not work correctly for input files that do not have an extension of .smtk (which seems odd), then the smtkCore WRITE operators should FAIL if the specified filename does not have the required .smtk extension. Presumably this would be a not-able-operate-failure.
2. But I suspect the underlying issue is at the application level, where modelbuilder registers the resource readers to paraview with the .smtk extension. If that is a more accurate depiction, then I think that:
- Our paraview extension code should enforce the .smtk extension, not smtkCore.
- And that code should not change the file extension under the covers, but instead refuse to save the resource if provided non-supported extension.
- And the smtkCore read/write operators should accept whatever filename is specified.
3. One result of this is that I should be able to write a different application using smtk and save resources with other file extensions, unless #1 truly is the case, that is, unless the read and write operators really are hard-coded to .smtk.