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

[John Tourtellott]

I haven't caught up with everything in this thread, but want to inject a
few comments of my own anyway. Sorry if they look like criticism or
complaints....

   - I also would NOT favor smtk automagically loading resources ad hoc. If
   resources are darn big, we could choke someone's desktop this -- better to
   make the app/user do that.
   - I also do NOT favor the idea of a member data for the resource "role",
   but perhaps I misunderstand the context (feel free to tell me mo'). To my
   mind, a resource can/will have multiple roles in a typical application.
      - a resource can have different roles with respect to different
      operators used in a workflow
      - a resource's role could change over its life cycle.
      - Side note: I wasn't sure if the "role" is intended to be persistent
      -- I am been presuming not, since different applications might have
      completely different roles for the same resource.
      - As for the OfflineComponent idea
      - I definitely like the concept and the reasoning behind it
      - in addition to the "resolve" method, it also needs an "error"
      method (perhaps that was implied and I missed it)
      - I am not sure it should be a subclass of Component, but instead an
      independent class. But this last point might be an implementation detail;
      plus I haven't actually looked at the Component API either...


On Thu, Mar 15, 2018 at 10:59 AM, David Thompson <david.thompson at kitware.com
> wrote:

>
> ...
>
> 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.
>
>
> Also, make an explicit Link class in resource that has a pure virtual
> resolve() method. Then there are no operations and thus no circular deps.
>
>     David
>
> _______________________________________________
> Smtk-developers mailing list
> Smtk-developers at smtk.org
> https://smtk.org/mailman/listinfo/smtk-developers
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://smtk.org/pipermail/smtk-developers/attachments/20180315/fe7b390f/attachment.html>