[Smtk-developers] Resource Proxies (not the ParaView kind)

[David Thompson]

Hi TJ,

>>> ... Can two resources link to the same resource?
>> 
>> Yes, I think this goes back to the bidirectional nature of relationships.
> 
> If this is the case, we are going to be adding some potential minefields in the resource logic. The infinite recursion kind. There are 1,000,000 ways that can go wrong, especially with the open-ended API we expose for resources.

Well, a simulation attribute and a mesh both need references to the same model, so we need 2 links to the same resource. And I don't see the problem with bidirectional links. You should only be able to link 2 objects if they are both in memory. Undoing links is simpler, since you should in theory be able to discard the unloaded resource if you are unwilling to load and reconcile it.

> 
>> ...
>> 4. Create smtk::resoource::OfflineComponent which inherits Component. It must point to a resource in the OFFLINE state. It should have a resolve() method that returns the proper value (obtained using the OfflineComponent's id()) if its parent resource is not OFFLINE.
> 
> This is pretty similar to what I first tried (except using resources, not components). The method resolve() pulls in the operation system which pulls in the attribute system and IO system, thus making SMTK Core a giant circular dependency again. I really, really don’t want to do this for the sake of syntactic sugar.

I don't think this is sugar, it's beef.

>> 5. Add an ivar to PersistentObject named m_links of type: std::map<std::string, std::set<PersistentObjectPtr>>. The string in the map is a "role". I think I can hear TJ's teeth gnashing, but perhaps he's just about to suggest some template-fu instead of a string. Whatever creates links must ensure they are bidirectional.
> 
> You can hear that from NC? :-)

Well, we can always use a boost multiindex for holding links. Or even simpler,

class Link {
    xxx m_whateverWeWantToIndexBy1; // e.g. std::string m_role
    ...
    xxx m_whateverWeWantToIndexByN;
    ResourcePtr m_from;
    ResourcePtr m_to;
};

class PersistentObject {
std::set<Link> m_links;
public: void visitLinks(std::function<...> visitor);
};

Are you saying you want links to be held by the resource manager?
Then we need to serialize/deserialize the manager, too... but I guess I am OK with that.

>> 6. Add a LinkManager class which Resource instances may hold... that allows applications to set a policy for how OfflineComponent::resolve() should behave.
> 
> This is a lot of machinery for what we are trying to accomplish. I like the idea of a policy for resolving resources, though.

Well, I don't see a way to avoid a link manager. We want its behavior to be separate from the resource manager and application-specific...

    David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://smtk.org/pipermail/smtk-developers/attachments/20180315/bed42329/attachment.html>