[Smtk-developers] Follow-up on resource metadata

[TJ Corona]

Hi David,

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? 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? That way, there is a single, explicitly declared location where the author of a resource must state how the resource is written and read to/from disk. Please let me know what you think!

Sincerely,
T.J.


> On Nov 15, 2017, at 10:06 AM, TJ Corona <tj.corona at kitware.com> wrote:
> 
>> On Nov 15, 2017, at 10:03 AM, David Thompson <david.thompson at kitware.com> wrote:
>> 
>> Hi TJ,
>> 
>>>>> ... We could definitely subclass Metadata, but I don’t see why we need to. Currently, the create(), read() and write() functors are public fields that can be reassigned (once operators are more decoupled from smtk::model, they should become operators); as such, I don’t see any benefit to subclassing.
>>>> 
>>>> My point is that every model resource should override create/read/write with the same 3 functors. It would be nice to inherit them.
>>> 
>>> I’m not sure I follow. If we assume that the three functors are instead smtk::operator::Operators (which is my intention, as soon as smtk::operator::* is usable), then these three operators will need to be explicitly provided by whoever registers the resource.
>> 
>> But at least the read and write operators will be the same for all: read = "load smtk model", write = "save smtk model". I thought that we agreed native model files would be handled by import/export operators.
> 
> Ah, gotcha. That’s a pretty good reason to subclass Metadata for model resources.