[Smtk-developers] Operation manaer

[David Thompson]

Hi all (but esp. TJ since you are working on it),

Should the resource manager own an operation manager?

Arguments for:

1. Resources will be read in by operations which resource metadata may point to. These operators should be managed by the same thing, not different ones or inconsistencies may creep in and cause difficult-to-diagnose bugs.

2. Operators are expected to register their acceptable inputs (and maybe outputs some day). Currently inputs can only be specified in terms of their SMTK representation (e.g., I only accept SMTK model edges) and not modeling kernel data (e.g., I only accept polygon-session model edges). We are talking about moving to a system where operators specify kernel-specific inputs using smtk::resource::Index values. But the mapping between these values and their associated metadata are aggregated by the resource manager.

3. It makes life easy for application developers.

Arguments agains:

1. Resource metadata may use any means to read/write/create resources and there is nothing currently that constrains these methods to use the same operation manager (or any at all, although at some point something has to own an attribute collection specifying operator defs -- the operators themselves don't).

2. Maybe there's something clever we can do to reference ResourceSubclass::Index at build time to explicitly register operators?

3. It constrains application developers (but I'm not sure whether it is a significant constraint).

	David