[Smtk-developers] Follow-up on resource metadata
David Thompson
david.thompson at kitware.com
Fri Nov 17 09:36:01 EST 2017
Hi TJ,
> I was thinking about our conversation below, and how the “load smtk model” and “save smtk model” operators perform load and save operations for all sessions. These operations must either directly or indirectly defer to the sessions for the actual reading and writing by looking for operators with specific “read” and “write” names, right?
Not entirely correct, but mostly. As part of loading the JSON file, they locate/create sessions (either existing ones in the model manager or create new ones via the SessionRegistrar) as specified in the file and then call createDelegate to get a SessionIODelegate object. If the session returns one, then a method is called on it to parse session-specific JSON. This **could** be (and was intended to be) a chance for the session to import native model files. However, the default implementation of the method asks the session for import/export operators by name. (I did not write that bit.)
> I worry that the implicit requirement of the existence of operators with specific names could be confusing to new developers (it sure threw me for a loop with the Capstone session). Rather than having the resource manager call the “load smtk model” and “save smtk model” operators, do you think these operators could call the resource manager’s methods?
I think you mean "the resource's methods." If so, that is possible and not objectionable, although I would prefer to return to original design above, with the exception that now the SessionRegistrar, not the model manager, would be queried for pre-existing sessions of the proper type.
David
More information about the Smtk-developers
mailing list