[Smtk-developers] Follow-up on resource metadata

[TJ Corona]

> On Nov 14, 2017, at 5:59 PM, 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. 

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

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?). 

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

Why would this be a problem for operators associated with the base session? Using the same inheritance chain trick that is in resource, we can automatically determine that an operator that applies to the base session can apply to a derived session (so no need to manually white-list it). Also using the same trick used in resource, the container of operators will be multi-indexed, so if the user/developer is interested in operators by name, by input type or output type (or anything else we want to use as an index), it will be only a couple lines of code.

> 	David