[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.

>> 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? I guess the SessionRegistrar. Also, we did this funky thing where the model manager adds an Entity record to itself for each of the session instances it owns -- that way an smtk::model::Model could report the session running its backend. At some point (please not now), we might eliminate that since all the models in the manager/resource will have the same session.

> It would also be nice if a set of operators specific to a given session could be identified by their input or output type, obviating the need for an additional operator management system (instead, we could simply filter by input/output type to get all operators appropriate for a given model/component).

If by "input or output type" you literally mean typeid(modelResource), then that will be a problem for operators inherited from the "base" session. We have said we want derived sessions to be able to pick and choose their operators, but having to explicitly import every one seems painful and error-prone as new ones are added.

	David