[Smtk-developers] Follow-up on resource metadata

[David Thompson]

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.

>>>> as we change the model manager into a resource, it goes from being a single instance with potentially multiple sessions to multiple instances, each with a single session.
>>> 
>>> For the model system (and each of its derived bridges), something needs to be "the resource” ...
>> 
>> I think we are on the same page and I did not mean to imply that turning the model manager into a resource was bad; merely that it has this implication for sessions. That's going to require some changes as the model manager now owns its sessions but now what will own them? ...
> 
> If sessions can be accessed via the model resource, then maybe it doesn’t really matter where they live (perhaps simply a shared or weak pointer within the resource?).

Maybe, but I think I prefer the SessionRegistrar so that there is a way to get a list of open sessions to present to the user.

    David