[Smtk-developers] Resource Proxies (not the ParaView kind)
John Tourtellott
john.tourtellott at kitware.com
Thu Mar 15 16:03:00 EDT 2018
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>
More information about the Smtk-developers
mailing list