From bob.obara at kitware.com Thu Mar 1 12:00:43 2018 From: bob.obara at kitware.com (Bob Obara) Date: Thu, 1 Mar 2018 12:00:43 -0500 Subject: [Smtk-developers] CMB Release 5.1.0 and SMTK Release 1.3.0 Message-ID: <616D7949-374F-4050-85D3-0C79D4F25645@kitware.com> Hi All, I would like to start the release process for some small improvements made to CMB and SMTK on their release branches. Does anyone have any changes they would like to have included before I start the process? Please let me know by the end of the day. Thanks! Bob Robert M. O'Bara, MEng. Assistant Director of Scientific Computing Kitware Inc. 28 Corporate Drive Suite 101 Clifton Park, NY 12065 Phone: (518) 881- 4931 -------------- next part -------------- An HTML attachment was scrubbed... URL: From haocheng.liu at kitware.com Thu Mar 1 13:41:09 2018 From: haocheng.liu at kitware.com (Haocheng Liu) Date: Thu, 1 Mar 2018 13:41:09 -0500 Subject: [Smtk-developers] CMB Release 5.1.0 and SMTK Release 1.3.0 In-Reply-To: <616D7949-374F-4050-85D3-0C79D4F25645@kitware.com> References: <616D7949-374F-4050-85D3-0C79D4F25645@kitware.com> Message-ID: Hi Bob, I've a fix for create instance functionality. I would merge my patch to SMTK and CMB release. On Thu, Mar 1, 2018 at 12:00 PM, Bob Obara wrote: > Hi All, > > I would like to start the release process for some small improvements made > to CMB and SMTK on their release branches. Does anyone have any changes > they would like to have included before I start the process? Please let me > know by the end of the day. > > Thanks! > > Bob > > Robert M. O'Bara, MEng. > Assistant Director of Scientific Computing > > Kitware Inc. > 28 Corporate Drive > Suite 101 > Clifton Park, NY 12065 > > Phone: (518) 881- 4931 <(518)%20881-4931> > > > > > > _______________________________________________ > Smtk-developers mailing list > Smtk-developers at smtk.org > https://smtk.org/mailman/listinfo/smtk-developers > > -- Best regards Haocheng Haocheng LIU Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4421 <(518)%20881-4421> -------------- next part -------------- An HTML attachment was scrubbed... URL: From tj.corona at kitware.com Wed Mar 14 20:00:22 2018 From: tj.corona at kitware.com (TJ Corona) Date: Wed, 14 Mar 2018 20:00:22 -0400 Subject: [Smtk-developers] Resource Proxies (not the ParaView kind) Message-ID: <9755E003-501D-4CB6-B17D-94A1CE6ABB37@kitware.com> Hi all, I have been working on resource links today. In the process, I decided to try and tackle the case where a resource has links to another resource, and we don?t want to load that resource until we need to. The problem I ran into is the open-ended nature of this task: ?until we need to? load a resource. 1. When do we ?need? a resource to load? When an operator uses it as a parameter? When a resource with links (think a model with an associated mesh) is operated on (if you remove a model face, should we remove the associated mesh part)? 2. If two resources link to the same resource proxy and one of them resolves that resource, do we expect the resource link in the other resource to automagically update itself? Can two resources link to the same resource? 3. Does this need to work in the absence of a resource manager (I hope not!)? The problem becomes much more complex when you take into account thread safety, where many things can try to resolve a proxy at once. I have some ideas for how this all should work, but I would really like to hear from you all what concrete examples need to be supported. Sincerely, T.J. Thomas J. Corona, Ph.D. Kitware, Inc. Senior R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4443 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tj.corona at kitware.com Wed Mar 14 20:31:28 2018 From: tj.corona at kitware.com (TJ Corona) Date: Wed, 14 Mar 2018 20:31:28 -0400 Subject: [Smtk-developers] Resource Proxies (not the ParaView kind) In-Reply-To: <9755E003-501D-4CB6-B17D-94A1CE6ABB37@kitware.com> References: <9755E003-501D-4CB6-B17D-94A1CE6ABB37@kitware.com> Message-ID: Let me start with my own two cents: 1. For now, we make the practice of loading a resource proxy completely manual. The proxy will satisfy some of the Resource API (location, id, type, inheritance) but that?s it. 2. No automagic updates. There will be an operation for resolving resource links for an existing resource. If one of its links has already been loaded, it will simply get the pointer to that resource (in the presence of a resource manager). With no resource manager, there?s no problem with loading the same resource twice if the user executes the ?ResolveResourceLinks? operator (or whatever it will be called). 3. Yes, this needs to work. Otherwise, the entire paradigm of meshing a model falls apart in the absence of a resource manager. By a) narrowing the API to only allow loading of resource links via the resource that linked it, and b) requiring that resolving resource proxies be done as an operation, I think we can get around the multithreading issues. Thoughts? > On Mar 14, 2018, at 8:00 PM, TJ Corona wrote: > > Hi all, > > I have been working on resource links today. In the process, I decided to try and tackle the case where a resource has links to another resource, and we don?t want to load that resource until we need to. The problem I ran into is the open-ended nature of this task: ?until we need to? load a resource. > > 1. When do we ?need? a resource to load? When an operator uses it as a parameter? When a resource with links (think a model with an associated mesh) is operated on (if you remove a model face, should we remove the associated mesh part)? > > 2. If two resources link to the same resource proxy and one of them resolves that resource, do we expect the resource link in the other resource to automagically update itself? Can two resources link to the same resource? > > 3. Does this need to work in the absence of a resource manager (I hope not!)? > > The problem becomes much more complex when you take into account thread safety, where many things can try to resolve a proxy at once. I have some ideas for how this all should work, but I would really like to hear from you all what concrete examples need to be supported. > > Sincerely, > T.J. > > Thomas J. Corona, Ph.D. > Kitware, Inc. > Senior R&D Engineer > 21 Corporate Drive > Clifton Park, NY 12065-8662 > Phone: 518-881-4443 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Thu Mar 15 09:36:34 2018 From: david.thompson at kitware.com (David Thompson) Date: Thu, 15 Mar 2018 09:36:34 -0400 Subject: [Smtk-developers] Resource Proxies (not the ParaView kind) In-Reply-To: <9755E003-501D-4CB6-B17D-94A1CE6ABB37@kitware.com> References: <9755E003-501D-4CB6-B17D-94A1CE6ABB37@kitware.com> Message-ID: Hi TJ, > I have been working on resource links today. ... Does this fit in with making smtk::resource::{Resource,Component} share a common base class (e.g., PersistentObject) so that components can link to resources and vice versa? I think that's part of some of our use cases (notably the export operator). > In the process, I decided to try and tackle the case where a resource has links to another resource, and we don?t want to load that resource until we need to. The problem I ran into is the open-ended nature of this task: ?until we need to? load a resource. I don't think it's open ended, so much as often the definition of "need" must be provided by a user (or a workflow), not a developer. > 1. When do we ?need? a resource to load? When an operator uses it as a parameter? When a resource with links (think a model with an associated mesh) is operated on (if you remove a model face, should we remove the associated mesh part)? Yes, links must be bidirectional so that a resource/component (let's just say "persistent object" from here on) can discover what links to it. Otherwise, it could be hard to avoid cyclic dependencies which we may want to prevent. > 2. If two resources link to the same resource proxy ... what's a resource _proxy_? (And where is that in the documentation? :-) > and one of them resolves that resource, do we expect the resource link in the other resource to automagically update itself? Can two resources link to the same resource? Yes, I think this goes back to the bidirectional nature of relationships. > 3. Does this need to work in the absence of a resource manager (I hope not!)? Everything I'm doing ends up having a resource manager, so I'm OK with it requiring a resource manager. > The problem becomes much more complex when you take into account thread safety, where many things can try to resolve a proxy at once. Again, I'm not sure what a proxy is. > I have some ideas for how this all should work, but I would really like to hear from you all what concrete examples need to be supported. 1. A mesh and model should be linked so that if a model gets modified, SMTK can reconcile (or unlink) linked meshes. We have talked about storing the "recipe" (sizing function) on the model so automatic remeshing _could_ happen (not that it should automatically). Another thing we could do to simplify the situation is to store the sizing function on the link itself. 2. Attribute associations are really links. You might load a simulation attribute resource without the model, but if you start to export the model might need to be loaded for the exporter. 3. Attribute RefItems are really links. a. An attribute holding solver parameters might refer to an inflow/outflow/wall boundary condition attribute or an initial condition attribute. In a complex case, it is conceivable that those attributes might even live in different resources -- although we don't do that today. However, ... b. I believe the "export" and "simulation" attributes are held in different resources today and "export" attributes reference "simulation" attributes. Certainly the export operator should be allowed to link to model, mesh, and attribute resources as well as components within them. 4. We have talked about storing attributes directly on meshes, but I don't have a specific use case in mind. David PS. Here's my 2? for how to handle links: 1. Create smtk::resource::PersistentObject which both Component and Resource inherit. 2. Add an ivar to PersistentObject named m_role of type std::string. 3. Change the "clean" ivar in Resource to an enum { CLEAN, DIRTY, OFFLINE } or add another bool that indicates the resource is not loaded so that access to its components is unavailable without further action. 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. 5. Add an ivar to PersistentObject named m_links of type: std::map>. 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. 6. Add a LinkManager class which Resource instances may hold... that allows applications to set a policy for how OfflineComponent::resolve() should behave. Now we can represent offline persistent objects. The application has a chance to decide how/whether to resolve unloaded resources at the time anyone attempts to resolve a link: if the resource is offline, the link-manager will load it or not based on either the workflow or user input. If a component is offline, again, the link-manager is invoked. Then functions in the SMTK library just need to examine whether offline persistent objects are resolved into online values before continuing. In fact, the entire process could be made invisible to users of links: you ask for a persistent object's links with a particular role and are only given those which resolved. If links are unresolved, the link-manager has an opportunity to remove the link on a case-by-case basis. Here's another 2?: add some more metadata (acceptable values in the form of multimap) to links and remove the attribute system's RefItem, ComponentItem, and ResourceItem. From tj.corona at kitware.com Thu Mar 15 10:28:32 2018 From: tj.corona at kitware.com (TJ Corona) Date: Thu, 15 Mar 2018 10:28:32 -0400 Subject: [Smtk-developers] Resource Proxies (not the ParaView kind) In-Reply-To: References: <9755E003-501D-4CB6-B17D-94A1CE6ABB37@kitware.com> Message-ID: <0BBC94AF-31BF-48CD-ACC9-1DCB2DCF2EC1@kitware.com> Hi David, Thanks for responding! >> I have been working on resource links today. ... > > Does this fit in with making smtk::resource::{Resource,Component} share a common base class (e.g., PersistentObject) so that components can link to resources and vice versa? I think that's part of some of our use cases (notably the export operator). It could, but I haven?t gone down that path yet. >> In the process, I decided to try and tackle the case where a resource has links to another resource, and we don?t want to load that resource until we need to. The problem I ran into is the open-ended nature of this task: ?until we need to? load a resource. > > I don't think it's open ended, so much as often the definition of "need" must be provided by a user (or a workflow), not a developer. Cool. I came to a similar conclusion. >> 1. When do we ?need? a resource to load? When an operator uses it as a parameter? When a resource with links (think a model with an associated mesh) is operated on (if you remove a model face, should we remove the associated mesh part)? > > Yes, links must be bidirectional so that a resource/component (let's just say "persistent object" from here on) can discover what links to it. Otherwise, it could be hard to avoid cyclic dependencies which we may want to prevent. Good to know, that wasn?t part of my original design. >> 2. If two resources link to the same resource proxy ... > > what's a resource _proxy_? (And where is that in the documentation? :-) Do you write documentation for a class you haven?t written? :-/ A resource proxy is identical to your OfflineResource. It is a proxy for a resource that can be retrieved when needed. Here and throughout, I am using the term ?proxy? as "a figure that can be used to represent the value of something in a calculation? (Google?s definition, not mine). >> and one of them resolves that resource, do we expect the resource link in the other resource to automagically update itself? 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. >> 3. Does this need to work in the absence of a resource manager (I hope not!)? > > Everything I'm doing ends up having a resource manager, so I'm OK with it requiring a resource manager. I actually decided to go the other way with this, avoiding requiring a resource manager to implement linking. >> The problem becomes much more complex when you take into account thread safety, where many things can try to resolve a proxy at once. > > Again, I'm not sure what a proxy is. See above. >> I have some ideas for how this all should work, but I would really like to hear from you all what concrete examples need to be supported. > > 1. A mesh and model should be linked so that if a model gets modified, SMTK can reconcile (or unlink) linked meshes. We have talked about storing the "recipe" (sizing function) on the model so automatic remeshing _could_ happen (not that it should automatically). Another thing we could do to simplify the situation is to store the sizing function on the link itself. > > 2. Attribute associations are really links. You might load a simulation attribute resource without the model, but if you start to export the model might need to be loaded for the exporter. > > 3. Attribute RefItems are really links. > a. An attribute holding solver parameters might refer to an inflow/outflow/wall boundary condition attribute or an initial condition attribute. In a complex case, it is conceivable that those attributes might even live in different resources -- although we don't do that today. However, ... > b. I believe the "export" and "simulation" attributes are held in different resources today and "export" attributes reference "simulation" attributes. Certainly the export operator should be allowed to link to model, mesh, and attribute resources as well as components within them. > > 4. We have talked about storing attributes directly on meshes, but I don't have a specific use case in mind. > > David > > PS. Here's my 2? for how to handle links: > > 1. Create smtk::resource::PersistentObject which both Component and Resource inherit. I agree, it may be the right time for this. > 2. Add an ivar to PersistentObject named m_role of type std::string. > 3. Change the "clean" ivar in Resource to an enum { CLEAN, DIRTY, OFFLINE } or add another bool that indicates the resource is not loaded so that access to its components is unavailable without further action. > 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. > 5. Add an ivar to PersistentObject named m_links of type: std::map>. 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? :-) > 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. > Now we can represent offline persistent objects. The application has a chance to decide how/whether to resolve unloaded resources at the time anyone attempts to resolve a link: if the resource is offline, the link-manager will load it or not based on either the workflow or user input. If a component is offline, again, the link-manager is invoked. Then functions in the SMTK library just need to examine whether offline persistent objects are resolved into online values before continuing. In fact, the entire process could be made invisible to users of links: you ask for a persistent object's links with a particular role and are only given those which resolved. If links are unresolved, the link-manager has an opportunity to remove the link on a case-by-case basis. > > Here's another 2?: add some more metadata (acceptable values in the form of multimap) to links and remove the attribute system's RefItem, ComponentItem, and ResourceItem. > On Mar 15, 2018, at 9:36 AM, David Thompson wrote: > > Hi TJ, > >> I have been working on resource links today. ... > > Does this fit in with making smtk::resource::{Resource,Component} share a common base class (e.g., PersistentObject) so that components can link to resources and vice versa? I think that's part of some of our use cases (notably the export operator). > >> In the process, I decided to try and tackle the case where a resource has links to another resource, and we don?t want to load that resource until we need to. The problem I ran into is the open-ended nature of this task: ?until we need to? load a resource. > > I don't think it's open ended, so much as often the definition of "need" must be provided by a user (or a workflow), not a developer. > >> 1. When do we ?need? a resource to load? When an operator uses it as a parameter? When a resource with links (think a model with an associated mesh) is operated on (if you remove a model face, should we remove the associated mesh part)? > > Yes, links must be bidirectional so that a resource/component (let's just say "persistent object" from here on) can discover what links to it. Otherwise, it could be hard to avoid cyclic dependencies which we may want to prevent. > >> 2. If two resources link to the same resource proxy ... > > what's a resource _proxy_? (And where is that in the documentation? :-) > >> and one of them resolves that resource, do we expect the resource link in the other resource to automagically update itself? Can two resources link to the same resource? > > Yes, I think this goes back to the bidirectional nature of relationships. > >> 3. Does this need to work in the absence of a resource manager (I hope not!)? > > Everything I'm doing ends up having a resource manager, so I'm OK with it requiring a resource manager. > >> The problem becomes much more complex when you take into account thread safety, where many things can try to resolve a proxy at once. > > Again, I'm not sure what a proxy is. > >> I have some ideas for how this all should work, but I would really like to hear from you all what concrete examples need to be supported. > > 1. A mesh and model should be linked so that if a model gets modified, SMTK can reconcile (or unlink) linked meshes. We have talked about storing the "recipe" (sizing function) on the model so automatic remeshing _could_ happen (not that it should automatically). Another thing we could do to simplify the situation is to store the sizing function on the link itself. > > 2. Attribute associations are really links. You might load a simulation attribute resource without the model, but if you start to export the model might need to be loaded for the exporter. > > 3. Attribute RefItems are really links. > a. An attribute holding solver parameters might refer to an inflow/outflow/wall boundary condition attribute or an initial condition attribute. In a complex case, it is conceivable that those attributes might even live in different resources -- although we don't do that today. However, ... > b. I believe the "export" and "simulation" attributes are held in different resources today and "export" attributes reference "simulation" attributes. Certainly the export operator should be allowed to link to model, mesh, and attribute resources as well as components within them. > > 4. We have talked about storing attributes directly on meshes, but I don't have a specific use case in mind. > > David > > PS. Here's my 2? for how to handle links: > > 1. Create smtk::resource::PersistentObject which both Component and Resource inherit. > 2. Add an ivar to PersistentObject named m_role of type std::string. > 3. Change the "clean" ivar in Resource to an enum { CLEAN, DIRTY, OFFLINE } or add another bool that indicates the resource is not loaded so that access to its components is unavailable without further action. > 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. > 5. Add an ivar to PersistentObject named m_links of type: std::map>. 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. > 6. Add a LinkManager class which Resource instances may hold... that allows applications to set a policy for how OfflineComponent::resolve() should behave. > > Now we can represent offline persistent objects. The application has a chance to decide how/whether to resolve unloaded resources at the time anyone attempts to resolve a link: if the resource is offline, the link-manager will load it or not based on either the workflow or user input. If a component is offline, again, the link-manager is invoked. Then functions in the SMTK library just need to examine whether offline persistent objects are resolved into online values before continuing. In fact, the entire process could be made invisible to users of links: you ask for a persistent object's links with a particular role and are only given those which resolved. If links are unresolved, the link-manager has an opportunity to remove the link on a case-by-case basis. > > Here's another 2?: add some more metadata (acceptable values in the form of multimap) to links and remove the attribute system's RefItem, ComponentItem, and ResourceItem. From david.thompson at kitware.com Thu Mar 15 10:52:47 2018 From: david.thompson at kitware.com (David Thompson) Date: Thu, 15 Mar 2018 10:52:47 -0400 Subject: [Smtk-developers] Resource Proxies (not the ParaView kind) In-Reply-To: <0BBC94AF-31BF-48CD-ACC9-1DCB2DCF2EC1@kitware.com> References: <9755E003-501D-4CB6-B17D-94A1CE6ABB37@kitware.com> <0BBC94AF-31BF-48CD-ACC9-1DCB2DCF2EC1@kitware.com> Message-ID: 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>. 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 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: From david.thompson at kitware.com Thu Mar 15 10:59:51 2018 From: david.thompson at kitware.com (David Thompson) Date: Thu, 15 Mar 2018 10:59:51 -0400 Subject: [Smtk-developers] Resource Proxies (not the ParaView kind) In-Reply-To: References: <9755E003-501D-4CB6-B17D-94A1CE6ABB37@kitware.com> <0BBC94AF-31BF-48CD-ACC9-1DCB2DCF2EC1@kitware.com> Message-ID: <50E7F347-542F-44DB-B827-45A086B7C538@kitware.com> >>> ... >>> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.tourtellott at kitware.com Thu Mar 15 16:03:00 2018 From: john.tourtellott at kitware.com (John Tourtellott) Date: Thu, 15 Mar 2018 16:03:00 -0400 Subject: [Smtk-developers] Resource Proxies (not the ParaView kind) In-Reply-To: <50E7F347-542F-44DB-B827-45A086B7C538@kitware.com> References: <9755E003-501D-4CB6-B17D-94A1CE6ABB37@kitware.com> <0BBC94AF-31BF-48CD-ACC9-1DCB2DCF2EC1@kitware.com> <50E7F347-542F-44DB-B827-45A086B7C538@kitware.com> Message-ID: 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 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: From david.thompson at kitware.com Tue Mar 20 16:06:30 2018 From: david.thompson at kitware.com (David Thompson) Date: Tue, 20 Mar 2018 16:06:30 -0400 Subject: [Smtk-developers] Pie in the sky Message-ID: <24D1A25C-34D0-47FC-83E7-CA7DED1E4259@kitware.com> Hi all, Following up on the "pie in the sky" talk we had at the meeting today, what about this directory-structure change to go along with the attribute-collection/model-manager/mesh-collection rename: core/smtk/{PublicPointerDefs,SharedFromThis, ...}.h core/smtk/{attribute, mesh, model}/Resource.{h,cxx} core/smtk/model/Session.h extension/smtk/model/polygon/{Resource,Session,...}.{h,cxx} extension/smtk/paraview/{server, components, ...} extension/smtk/qt/{qtAttributeView,...}.{h,cxx} extension/smtk/vtk/{source, ...} testing/smtk/{attribute, mesh, model}/{cxx,python}/... applications/{template-editor, attribute-preview, ...} cmake data doc/{userguide,tutorials,reference} python/smtk/{__init__.py, testing.py, simple.py} utilities Everything in core would become smtkCore. Subdirectories of extension/smtk would be separate projects with their own library(ies). In the end, projects in both core and extensions would install their public headers to ${CMAKE_INSTALL_PREFIX}/include/smtk/.... That way, directories could always correspond to namespaces (starting with "smtk", not core or extension) and there wouldn't be a question any more about whether Qt stuff should live in smtk::extension or not -- if it lived in a namespace at all, it would be smtk::qt. Moving testing out of the core directory would make it clear that tests could depend on extensions (such as polygon/discrete/mesh model resources). Tests would live in the directory/namespace of the most abstract thing they tested, so a test of the model resource that just happened to use a polygon model would live in testing/smtk/model while tests of the polygon session would live in testing/smtk/model/polygon. David From tj.corona at kitware.com Tue Mar 20 16:09:39 2018 From: tj.corona at kitware.com (TJ Corona) Date: Tue, 20 Mar 2018 16:09:39 -0400 Subject: [Smtk-developers] Pie in the sky In-Reply-To: <24D1A25C-34D0-47FC-83E7-CA7DED1E4259@kitware.com> References: <24D1A25C-34D0-47FC-83E7-CA7DED1E4259@kitware.com> Message-ID: <658F1E32-F868-4021-BC76-95B5ACDF201E@kitware.com> +1 In this configuration, where would the Pybind11 binding code and nlohmann json code go? > On Mar 20, 2018, at 4:06 PM, David Thompson wrote: > > Hi all, > > Following up on the "pie in the sky" talk we had at the meeting today, what about this directory-structure change to go along with the attribute-collection/model-manager/mesh-collection rename: > > core/smtk/{PublicPointerDefs,SharedFromThis, ...}.h > core/smtk/{attribute, mesh, model}/Resource.{h,cxx} > core/smtk/model/Session.h > > extension/smtk/model/polygon/{Resource,Session,...}.{h,cxx} > extension/smtk/paraview/{server, components, ...} > extension/smtk/qt/{qtAttributeView,...}.{h,cxx} > extension/smtk/vtk/{source, ...} > > testing/smtk/{attribute, mesh, model}/{cxx,python}/... > > applications/{template-editor, attribute-preview, ...} > cmake > data > doc/{userguide,tutorials,reference} > python/smtk/{__init__.py, testing.py, simple.py} > utilities > > Everything in core would become smtkCore. Subdirectories of extension/smtk would be separate projects with their own library(ies). In the end, projects in both core and extensions would install their public headers to ${CMAKE_INSTALL_PREFIX}/include/smtk/.... That way, directories could always correspond to namespaces (starting with "smtk", not core or extension) and there wouldn't be a question any more about whether Qt stuff should live in smtk::extension or not -- if it lived in a namespace at all, it would be smtk::qt. > > Moving testing out of the core directory would make it clear that tests could depend on extensions (such as polygon/discrete/mesh model resources). Tests would live in the directory/namespace of the most abstract thing they tested, so a test of the model resource that just happened to use a polygon model would live in testing/smtk/model while tests of the polygon session would live in testing/smtk/model/polygon. > > David > _______________________________________________ > Smtk-developers mailing list > Smtk-developers at smtk.org > https://smtk.org/mailman/listinfo/smtk-developers From david.thompson at kitware.com Tue Mar 20 16:25:32 2018 From: david.thompson at kitware.com (David Thompson) Date: Tue, 20 Mar 2018 16:25:32 -0400 Subject: [Smtk-developers] Pie in the sky In-Reply-To: <658F1E32-F868-4021-BC76-95B5ACDF201E@kitware.com> References: <24D1A25C-34D0-47FC-83E7-CA7DED1E4259@kitware.com> <658F1E32-F868-4021-BC76-95B5ACDF201E@kitware.com> Message-ID: <765C17E2-C5D8-486E-965C-1A923DE0DEE6@kitware.com> > In this configuration, where would the Pybind11 binding code and nlohmann json code go? I assumed they would stay as subdirectories of whatever source they wrap/serialize, but we could move them up to core/json/smtk/{attribute, mesh, model}/jsonResource.{h,cxx} core/pybind11/smtk/{attribute, mesh, model}/Py{Attribute, Mesh, Model}.cxx extension/json/smtk/{attribute, mesh, model}/jsonResource.{h,cxx} extension/pybind11/smtk/{attribute, mesh, model}/Py{Attribute, Mesh, Model}.cxx if you prefer. David > >> On Mar 20, 2018, at 4:06 PM, David Thompson wrote: >> >> Hi all, >> >> Following up on the "pie in the sky" talk we had at the meeting today, what about this directory-structure change to go along with the attribute-collection/model-manager/mesh-collection rename: >> >> core/smtk/{PublicPointerDefs,SharedFromThis, ...}.h >> core/smtk/{attribute, mesh, model}/Resource.{h,cxx} >> core/smtk/model/Session.h >> >> extension/smtk/model/polygon/{Resource,Session,...}.{h,cxx} >> extension/smtk/paraview/{server, components, ...} >> extension/smtk/qt/{qtAttributeView,...}.{h,cxx} >> extension/smtk/vtk/{source, ...} >> >> testing/smtk/{attribute, mesh, model}/{cxx,python}/... >> >> applications/{template-editor, attribute-preview, ...} >> cmake >> data >> doc/{userguide,tutorials,reference} >> python/smtk/{__init__.py, testing.py, simple.py} >> utilities >> >> Everything in core would become smtkCore. Subdirectories of extension/smtk would be separate projects with their own library(ies). In the end, projects in both core and extensions would install their public headers to ${CMAKE_INSTALL_PREFIX}/include/smtk/.... That way, directories could always correspond to namespaces (starting with "smtk", not core or extension) and there wouldn't be a question any more about whether Qt stuff should live in smtk::extension or not -- if it lived in a namespace at all, it would be smtk::qt. >> >> Moving testing out of the core directory would make it clear that tests could depend on extensions (such as polygon/discrete/mesh model resources). Tests would live in the directory/namespace of the most abstract thing they tested, so a test of the model resource that just happened to use a polygon model would live in testing/smtk/model while tests of the polygon session would live in testing/smtk/model/polygon. >> >> David >> _______________________________________________ >> Smtk-developers mailing list >> Smtk-developers at smtk.org >> https://smtk.org/mailman/listinfo/smtk-developers > From haocheng.liu at kitware.com Tue Mar 20 16:28:32 2018 From: haocheng.liu at kitware.com (Haocheng Liu) Date: Tue, 20 Mar 2018 16:28:32 -0400 Subject: [Smtk-developers] Pie in the sky In-Reply-To: <765C17E2-C5D8-486E-965C-1A923DE0DEE6@kitware.com> References: <24D1A25C-34D0-47FC-83E7-CA7DED1E4259@kitware.com> <658F1E32-F868-4021-BC76-95B5ACDF201E@kitware.com> <765C17E2-C5D8-486E-965C-1A923DE0DEE6@kitware.com> Message-ID: I vote for putting them in the subdirectories of whatever source they wrap/serialize since each of them is associated with a specific file/class. On Tue, Mar 20, 2018 at 4:25 PM, David Thompson wrote: > > In this configuration, where would the Pybind11 binding code and > nlohmann json code go? > > I assumed they would stay as subdirectories of whatever source they > wrap/serialize, but we could move them up to > > core/json/smtk/{attribute, mesh, model}/jsonResource.{h,cxx} > core/pybind11/smtk/{attribute, mesh, model}/Py{Attribute, Mesh, > Model}.cxx > > extension/json/smtk/{attribute, mesh, model}/jsonResource.{h,cxx} > extension/pybind11/smtk/{attribute, mesh, model}/Py{Attribute, Mesh, > Model}.cxx > > if you prefer. > > David > > > >> On Mar 20, 2018, at 4:06 PM, David Thompson > wrote: > >> > >> Hi all, > >> > >> Following up on the "pie in the sky" talk we had at the meeting today, > what about this directory-structure change to go along with the > attribute-collection/model-manager/mesh-collection rename: > >> > >> core/smtk/{PublicPointerDefs,SharedFromThis, ...}.h > >> core/smtk/{attribute, mesh, model}/Resource.{h,cxx} > >> core/smtk/model/Session.h > >> > >> extension/smtk/model/polygon/{Resource,Session,...}.{h,cxx} > >> extension/smtk/paraview/{server, components, ...} > >> extension/smtk/qt/{qtAttributeView,...}.{h,cxx} > >> extension/smtk/vtk/{source, ...} > >> > >> testing/smtk/{attribute, mesh, model}/{cxx,python}/... > >> > >> applications/{template-editor, attribute-preview, ...} > >> cmake > >> data > >> doc/{userguide,tutorials,reference} > >> python/smtk/{__init__.py, testing.py, simple.py} > >> utilities > >> > >> Everything in core would become smtkCore. Subdirectories of > extension/smtk would be separate projects with their own library(ies). In > the end, projects in both core and extensions would install their public > headers to ${CMAKE_INSTALL_PREFIX}/include/smtk/.... That way, > directories could always correspond to namespaces (starting with "smtk", > not core or extension) and there wouldn't be a question any more about > whether Qt stuff should live in smtk::extension or not -- if it lived in a > namespace at all, it would be smtk::qt. > >> > >> Moving testing out of the core directory would make it clear that tests > could depend on extensions (such as polygon/discrete/mesh model resources). > Tests would live in the directory/namespace of the most abstract thing they > tested, so a test of the model resource that just happened to use a polygon > model would live in testing/smtk/model while tests of the polygon session > would live in testing/smtk/model/polygon. > >> > >> David > >> _______________________________________________ > >> Smtk-developers mailing list > >> Smtk-developers at smtk.org > >> https://smtk.org/mailman/listinfo/smtk-developers > > > > _______________________________________________ > Smtk-developers mailing list > Smtk-developers at smtk.org > https://smtk.org/mailman/listinfo/smtk-developers > -- Best regards Haocheng Haocheng LIU Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4421 <(518)%20881-4421> -------------- next part -------------- An HTML attachment was scrubbed... URL: From tj.corona at kitware.com Tue Mar 20 16:33:06 2018 From: tj.corona at kitware.com (TJ Corona) Date: Tue, 20 Mar 2018 16:33:06 -0400 Subject: [Smtk-developers] Pie in the sky In-Reply-To: References: <24D1A25C-34D0-47FC-83E7-CA7DED1E4259@kitware.com> <658F1E32-F868-4021-BC76-95B5ACDF201E@kitware.com> <765C17E2-C5D8-486E-965C-1A923DE0DEE6@kitware.com> Message-ID: Me too. Other code may ?extend? smtk, but wrapping code requires the wrapped code for context. > On Mar 20, 2018, at 4:28 PM, Haocheng Liu wrote: > > I vote for putting them in the subdirectories of whatever source they wrap/serialize since each of them is associated with a specific file/class. > > On Tue, Mar 20, 2018 at 4:25 PM, David Thompson > wrote: > > In this configuration, where would the Pybind11 binding code and nlohmann json code go? > > I assumed they would stay as subdirectories of whatever source they wrap/serialize, but we could move them up to > > core/json/smtk/{attribute, mesh, model}/jsonResource.{h,cxx} > core/pybind11/smtk/{attribute, mesh, model}/Py{Attribute, Mesh, Model}.cxx > > extension/json/smtk/{attribute, mesh, model}/jsonResource.{h,cxx} > extension/pybind11/smtk/{attribute, mesh, model}/Py{Attribute, Mesh, Model}.cxx > > if you prefer. > > David > > > >> On Mar 20, 2018, at 4:06 PM, David Thompson > wrote: > >> > >> Hi all, > >> > >> Following up on the "pie in the sky" talk we had at the meeting today, what about this directory-structure change to go along with the attribute-collection/model-manager/mesh-collection rename: > >> > >> core/smtk/{PublicPointerDefs,SharedFromThis, ...}.h > >> core/smtk/{attribute, mesh, model}/Resource.{h,cxx} > >> core/smtk/model/Session.h > >> > >> extension/smtk/model/polygon/{Resource,Session,...}.{h,cxx} > >> extension/smtk/paraview/{server, components, ...} > >> extension/smtk/qt/{qtAttributeView,...}.{h,cxx} > >> extension/smtk/vtk/{source, ...} > >> > >> testing/smtk/{attribute, mesh, model}/{cxx,python}/... > >> > >> applications/{template-editor, attribute-preview, ...} > >> cmake > >> data > >> doc/{userguide,tutorials,reference} > >> python/smtk/{__init__.py, testing.py, simple.py} > >> utilities > >> > >> Everything in core would become smtkCore. Subdirectories of extension/smtk would be separate projects with their own library(ies). In the end, projects in both core and extensions would install their public headers to ${CMAKE_INSTALL_PREFIX}/include/smtk/.... That way, directories could always correspond to namespaces (starting with "smtk", not core or extension) and there wouldn't be a question any more about whether Qt stuff should live in smtk::extension or not -- if it lived in a namespace at all, it would be smtk::qt. > >> > >> Moving testing out of the core directory would make it clear that tests could depend on extensions (such as polygon/discrete/mesh model resources). Tests would live in the directory/namespace of the most abstract thing they tested, so a test of the model resource that just happened to use a polygon model would live in testing/smtk/model while tests of the polygon session would live in testing/smtk/model/polygon. > >> > >> David > >> _______________________________________________ > >> Smtk-developers mailing list > >> Smtk-developers at smtk.org > >> https://smtk.org/mailman/listinfo/smtk-developers > > > > _______________________________________________ > Smtk-developers mailing list > Smtk-developers at smtk.org > https://smtk.org/mailman/listinfo/smtk-developers > > > > -- > Best regards > Haocheng > > Haocheng LIU > Kitware, Inc. > R&D Engineer > 21 Corporate Drive > Clifton Park, NY 12065-8662 > Phone: 518-881-4421 -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Tue Mar 20 16:33:12 2018 From: david.thompson at kitware.com (David Thompson) Date: Tue, 20 Mar 2018 16:33:12 -0400 Subject: [Smtk-developers] Pie in the sky In-Reply-To: References: <24D1A25C-34D0-47FC-83E7-CA7DED1E4259@kitware.com> <658F1E32-F868-4021-BC76-95B5ACDF201E@kitware.com> <765C17E2-C5D8-486E-965C-1A923DE0DEE6@kitware.com> Message-ID: > I vote for putting them in the subdirectories of whatever source they wrap/serialize since each of them is associated with a specific file/class. I think TJ was hinting that we we do this: > core/json/smtk/{attribute, mesh, model}/jsonResource.{h,cxx} > core/pybind11/smtk/{attribute, mesh, model}/Py{Attribute, Mesh, Model}.cxx > > extension/json/smtk/{attribute, mesh, model}/jsonResource.{h,cxx} > extension/pybind11/smtk/{attribute, mesh, model}/Py{Attribute, Mesh, Model}.cxx then everything in core/smtk is in the smtkCore library; everything in the core/json directory could live in an smtkCoreJSON directory, etc. In general, the pattern would be that no two libraries have code in the same source directory. David From tj.corona at kitware.com Tue Mar 20 16:47:16 2018 From: tj.corona at kitware.com (TJ Corona) Date: Tue, 20 Mar 2018 16:47:16 -0400 Subject: [Smtk-developers] Pie in the sky In-Reply-To: References: <24D1A25C-34D0-47FC-83E7-CA7DED1E4259@kitware.com> <658F1E32-F868-4021-BC76-95B5ACDF201E@kitware.com> <765C17E2-C5D8-486E-965C-1A923DE0DEE6@kitware.com> Message-ID: <78EBEDAB-2047-4232-BD95-3FEC78039071@kitware.com> Maybe we could do something like Core/smtk/{attribute, mesh, model}/binding/{json, pybind11}/{Pybind, json}Resource.{h, cxx} > On Mar 20, 2018, at 4:33 PM, David Thompson wrote: > >> I vote for putting them in the subdirectories of whatever source they wrap/serialize since each of them is associated with a specific file/class. > > I think TJ was hinting that we we do this: > >> core/json/smtk/{attribute, mesh, model}/jsonResource.{h,cxx} >> core/pybind11/smtk/{attribute, mesh, model}/Py{Attribute, Mesh, Model}.cxx >> >> extension/json/smtk/{attribute, mesh, model}/jsonResource.{h,cxx} >> extension/pybind11/smtk/{attribute, mesh, model}/Py{Attribute, Mesh, Model}.cxx > > then everything in core/smtk is in the smtkCore library; everything in the core/json directory could live in an smtkCoreJSON directory, etc. In general, the pattern would be that no two libraries have code in the same source directory. > > David From david.thompson at kitware.com Tue Mar 20 17:02:22 2018 From: david.thompson at kitware.com (David Thompson) Date: Tue, 20 Mar 2018 17:02:22 -0400 Subject: [Smtk-developers] Pie in the sky In-Reply-To: <78EBEDAB-2047-4232-BD95-3FEC78039071@kitware.com> References: <24D1A25C-34D0-47FC-83E7-CA7DED1E4259@kitware.com> <658F1E32-F868-4021-BC76-95B5ACDF201E@kitware.com> <765C17E2-C5D8-486E-965C-1A923DE0DEE6@kitware.com> <78EBEDAB-2047-4232-BD95-3FEC78039071@kitware.com> Message-ID: > Maybe we could do something like > Core/smtk/{attribute, mesh, model}/binding/{json, pybind11}/{Pybind, json}Resource.{h, cxx} Hrmmm, to me that feels like adding an extra directory (named "binding") without reason compared to the "just add them to subdirectories of where the source actually lives": core/smtk/{attribute, mesh, model}/json/jsonResource.{h,cxx} core/smtk/{attribute, mesh, model}/pybind11/Py{Attribute, Mesh, Model}.cxx extension/smtk/{attribute, mesh, model}/json/jsonExtensionClass.{h,cxx} extension/smtk/{attribute, mesh, model}/pybind11/PyExtensionName.cxx without gaining any of the benefits of separating code from different libraries. I'm OK with breaking the "no intermingled source" rule and putting the json/python stuff inside core/smtk/foo/{json,pybind}, but not the "no superfluous directories" rule that adding core/smtk/foo/binding/{json,pybind} entails. David From tj.corona at kitware.com Tue Mar 20 17:09:58 2018 From: tj.corona at kitware.com (TJ Corona) Date: Tue, 20 Mar 2018 17:09:58 -0400 Subject: [Smtk-developers] Pie in the sky In-Reply-To: References: <24D1A25C-34D0-47FC-83E7-CA7DED1E4259@kitware.com> <658F1E32-F868-4021-BC76-95B5ACDF201E@kitware.com> <765C17E2-C5D8-486E-965C-1A923DE0DEE6@kitware.com> <78EBEDAB-2047-4232-BD95-3FEC78039071@kitware.com> Message-ID: <64BD06B5-CB73-4051-8112-25F94F9F21A8@kitware.com> > the "no superfluous directories" rule When was this made a rule? I LOVE superfluous directories! ;-) > On Mar 20, 2018, at 5:02 PM, David Thompson wrote: > >> Maybe we could do something like >> Core/smtk/{attribute, mesh, model}/binding/{json, pybind11}/{Pybind, json}Resource.{h, cxx} > > Hrmmm, to me that feels like adding an extra directory (named "binding") without reason compared to the "just add them to subdirectories of where the source actually lives": > > core/smtk/{attribute, mesh, model}/json/jsonResource.{h,cxx} > core/smtk/{attribute, mesh, model}/pybind11/Py{Attribute, Mesh, Model}.cxx > > extension/smtk/{attribute, mesh, model}/json/jsonExtensionClass.{h,cxx} > extension/smtk/{attribute, mesh, model}/pybind11/PyExtensionName.cxx > > without gaining any of the benefits of separating code from different libraries. > > I'm OK with breaking the "no intermingled source" rule and putting the json/python stuff inside core/smtk/foo/{json,pybind}, but not the "no superfluous directories" rule that adding core/smtk/foo/binding/{json,pybind} entails. > > David From bob.obara at kitware.com Tue Mar 20 17:19:32 2018 From: bob.obara at kitware.com (Bob Obara) Date: Tue, 20 Mar 2018 17:19:32 -0400 Subject: [Smtk-developers] Pie in the sky In-Reply-To: References: <24D1A25C-34D0-47FC-83E7-CA7DED1E4259@kitware.com> <658F1E32-F868-4021-BC76-95B5ACDF201E@kitware.com> <765C17E2-C5D8-486E-965C-1A923DE0DEE6@kitware.com> Message-ID: <095344D5-3A59-4915-B20A-C4F673489B95@kitware.com> I?m ok either though I tend to like keeping ?like? files close so having a json or pybind subdirectory in the same directory as the source file does remind you that you might need to make changes to them as well. What about the stuff under bridge :) - should it be smtk/extension/session/polygon, or smtk/extension/modeler/polygon or maybe smtk/modeler/polygon? Bob Robert M. O'Bara, MEng. Assistant Director of Scientific Computing Kitware Inc. 28 Corporate Drive Suite 101 Clifton Park, NY 12065 Phone: (518) 881- 4931 > On Mar 20, 2018, at 4:33 PM, David Thompson wrote: > >> I vote for putting them in the subdirectories of whatever source they wrap/serialize since each of them is associated with a specific file/class. > > I think TJ was hinting that we we do this: > >> core/json/smtk/{attribute, mesh, model}/jsonResource.{h,cxx} >> core/pybind11/smtk/{attribute, mesh, model}/Py{Attribute, Mesh, Model}.cxx >> >> extension/json/smtk/{attribute, mesh, model}/jsonResource.{h,cxx} >> extension/pybind11/smtk/{attribute, mesh, model}/Py{Attribute, Mesh, Model}.cxx > > then everything in core/smtk is in the smtkCore library; everything in the core/json directory could live in an smtkCoreJSON directory, etc. In general, the pattern would be that no two libraries have code in the same source directory. > > 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: From david.thompson at kitware.com Wed Mar 21 08:51:22 2018 From: david.thompson at kitware.com (David Thompson) Date: Wed, 21 Mar 2018 08:51:22 -0400 Subject: [Smtk-developers] Pie in the sky In-Reply-To: <095344D5-3A59-4915-B20A-C4F673489B95@kitware.com> References: <24D1A25C-34D0-47FC-83E7-CA7DED1E4259@kitware.com> <658F1E32-F868-4021-BC76-95B5ACDF201E@kitware.com> <765C17E2-C5D8-486E-965C-1A923DE0DEE6@kitware.com> <095344D5-3A59-4915-B20A-C4F673489B95@kitware.com> Message-ID: <0E2E3D80-3A3D-4C6B-8816-4B0340E45CA5@kitware.com> > I?m ok either though I tend to like keeping ?like? files close so having a json or pybind subdirectory in the same directory as the source file does remind you that you might need to make changes to them as well. I agree that's useful. It sounds like everyone's in agreement not to force separate directories for each library's source files -- at least for wrapping and serialization. > What about the stuff under bridge :) - should it be > > smtk/extension/session/polygon, > or > smtk/extension/modeler/polygon > or maybe > smtk/modeler/polygon? In my examples, I put it under extension/smtk/model/polygon so it would live in the smtk::model::polygon namespace. That eliminates the need for another namespace like kernel, session, or modeler. I would prefer to keep namespaces shallow and broad, however if you want to be more explicit at the top-level of SMTK's sources, we could split the extensions directory into different functional categories: modeler/smtk/model/polygon modeler/smtk/model/discrete mesher/smtk/mesh/triangle mesher/smtk/mesh/netgen gui/smtk/qt gui/smtk/paraview gui/smtk/vtk instead of just putting them all in extension/smtk/... Since no one appears to mind libraries with some source-dir overlap, maybe we could eliminate core and extensions at the top level and just have smtk/attribute/core smtk/model/{core, polygon, discrete, ...} smtk/mesh/{core, moab, vtk, pumi, ...} smtk/qt smtk/vtk smtk/paraview/{server, components, ...} and just make one library out of smtk/*/core. Or to be more consistent, smtk/core/{attribute, mesh, model, operation, resource} smtk/{discrete, mesh, polygon, ...}/{operators, environment, ...} smtk/{qt, paraview, python, vtk} would put all of smtkCore in smtk/core/* (along with its json, pybind, and environment libraries). That simplifies the directory layout a bit, but now what are the namespaces? Would we have smtk::core::model but smtk::polygon for the polygon session? I like keeping namespaces that correspond to directory trees. David >> On Mar 20, 2018, at 4:33 PM, David Thompson wrote: >> >>> I vote for putting them in the subdirectories of whatever source they wrap/serialize since each of them is associated with a specific file/class. >> >> I think TJ was hinting that we we do this: >> >>> core/json/smtk/{attribute, mesh, model}/jsonResource.{h,cxx} >>> core/pybind11/smtk/{attribute, mesh, model}/Py{Attribute, Mesh, Model}.cxx >>> >>> extension/json/smtk/{attribute, mesh, model}/jsonResource.{h,cxx} >>> extension/pybind11/smtk/{attribute, mesh, model}/Py{Attribute, Mesh, Model}.cxx >> >> then everything in core/smtk is in the smtkCore library; everything in the core/json directory could live in an smtkCoreJSON directory, etc. In general, the pattern would be that no two libraries have code in the same source directory. >> >> David >> _______________________________________________ >> Smtk-developers mailing list >> Smtk-developers at smtk.org >> https://smtk.org/mailman/listinfo/smtk-developers > From tj.corona at kitware.com Wed Mar 21 09:09:56 2018 From: tj.corona at kitware.com (TJ Corona) Date: Wed, 21 Mar 2018 09:09:56 -0400 Subject: [Smtk-developers] Pie in the sky In-Reply-To: <0E2E3D80-3A3D-4C6B-8816-4B0340E45CA5@kitware.com> References: <24D1A25C-34D0-47FC-83E7-CA7DED1E4259@kitware.com> <658F1E32-F868-4021-BC76-95B5ACDF201E@kitware.com> <765C17E2-C5D8-486E-965C-1A923DE0DEE6@kitware.com> <095344D5-3A59-4915-B20A-C4F673489B95@kitware.com> <0E2E3D80-3A3D-4C6B-8816-4B0340E45CA5@kitware.com> Message-ID: > Since no one appears to mind libraries with some source-dir overlap, maybe we could eliminate core and extensions at the top level and just have > > smtk/attribute/core > smtk/model/{core, polygon, discrete, ...} > smtk/mesh/{core, moab, vtk, pumi, ...} > smtk/qt > smtk/vtk > smtk/paraview/{server, components, ...} > > and just make one library out of smtk/*/core. Or to be more consistent, > > smtk/core/{attribute, mesh, model, operation, resource} > smtk/{discrete, mesh, polygon, ...}/{operators, environment, ...} > smtk/{qt, paraview, python, vtk} We are still on the topic of pies in the sky, right? I would really, really like to see the smtk core library turn into something more granular. In addition to having smaller libraries, forcing developers to be mindful of directional dependencies would enforce better coding practices. While the directory structure neither helps nor hurts this goal, a good first step would be to remove core as a directory. > On Mar 21, 2018, at 8:51 AM, David Thompson wrote: > >> I?m ok either though I tend to like keeping ?like? files close so having a json or pybind subdirectory in the same directory as the source file does remind you that you might need to make changes to them as well. > > I agree that's useful. It sounds like everyone's in agreement not to force separate directories for each library's source files -- at least for wrapping and serialization. > >> What about the stuff under bridge :) - should it be >> >> smtk/extension/session/polygon, >> or >> smtk/extension/modeler/polygon >> or maybe >> smtk/modeler/polygon? > > In my examples, I put it under extension/smtk/model/polygon so it would live in the smtk::model::polygon namespace. That eliminates the need for another namespace like kernel, session, or modeler. I would prefer to keep namespaces shallow and broad, however if you want to be more explicit at the top-level of SMTK's sources, we could split the extensions directory into different functional categories: > > modeler/smtk/model/polygon > modeler/smtk/model/discrete > > mesher/smtk/mesh/triangle > mesher/smtk/mesh/netgen > > gui/smtk/qt > gui/smtk/paraview > gui/smtk/vtk > > instead of just putting them all in extension/smtk/... > > Since no one appears to mind libraries with some source-dir overlap, maybe we could eliminate core and extensions at the top level and just have > > smtk/attribute/core > smtk/model/{core, polygon, discrete, ...} > smtk/mesh/{core, moab, vtk, pumi, ...} > smtk/qt > smtk/vtk > smtk/paraview/{server, components, ...} > > and just make one library out of smtk/*/core. Or to be more consistent, > > smtk/core/{attribute, mesh, model, operation, resource} > smtk/{discrete, mesh, polygon, ...}/{operators, environment, ...} > smtk/{qt, paraview, python, vtk} > > would put all of smtkCore in smtk/core/* (along with its json, pybind, and environment libraries). That simplifies the directory layout a bit, but now what are the namespaces? Would we have smtk::core::model but smtk::polygon for the polygon session? I like keeping namespaces that correspond to directory trees. > > David > >>> On Mar 20, 2018, at 4:33 PM, David Thompson wrote: >>> >>>> I vote for putting them in the subdirectories of whatever source they wrap/serialize since each of them is associated with a specific file/class. >>> >>> I think TJ was hinting that we we do this: >>> >>>> core/json/smtk/{attribute, mesh, model}/jsonResource.{h,cxx} >>>> core/pybind11/smtk/{attribute, mesh, model}/Py{Attribute, Mesh, Model}.cxx >>>> >>>> extension/json/smtk/{attribute, mesh, model}/jsonResource.{h,cxx} >>>> extension/pybind11/smtk/{attribute, mesh, model}/Py{Attribute, Mesh, Model}.cxx >>> >>> then everything in core/smtk is in the smtkCore library; everything in the core/json directory could live in an smtkCoreJSON directory, etc. In general, the pattern would be that no two libraries have code in the same source directory. >>> >>> David >>> _______________________________________________ >>> Smtk-developers mailing list >>> Smtk-developers at smtk.org >>> https://smtk.org/mailman/listinfo/smtk-developers >> > > _______________________________________________ > Smtk-developers mailing list > Smtk-developers at smtk.org > https://smtk.org/mailman/listinfo/smtk-developers From david.thompson at kitware.com Wed Mar 21 10:10:08 2018 From: david.thompson at kitware.com (David Thompson) Date: Wed, 21 Mar 2018 10:10:08 -0400 Subject: [Smtk-developers] Pie in the sky In-Reply-To: References: <24D1A25C-34D0-47FC-83E7-CA7DED1E4259@kitware.com> <658F1E32-F868-4021-BC76-95B5ACDF201E@kitware.com> <765C17E2-C5D8-486E-965C-1A923DE0DEE6@kitware.com> <095344D5-3A59-4915-B20A-C4F673489B95@kitware.com> <0E2E3D80-3A3D-4C6B-8816-4B0340E45CA5@kitware.com> Message-ID: > We are still on the topic of pies in the sky, right? I would really, really like to see the smtk core library turn into something more granular. In addition to having smaller libraries, forcing developers to be mindful of directional dependencies would enforce better coding practices. While the directory structure neither helps nor hurts this goal, a good first step would be to remove core as a directory. If we follow the VTK practice and use a 2-level hierarchy, then + smtkCommonCore (what was smtk::common, the namespace would become smtk::core?), + smtkCommonResource (smtk::resource), + smtkCommonSystems (smtk::operation and smtk::attribute at a minimum ? they are codependent ? and perhaps smtk::model and smtk::mesh since it seems odd not to include them if we must include attribute), + smtkQtCore, + smtkPV{Server, Components, ...}, and + smtkVTK{Source, IO, ...}. Is that what you had in mind? David > On Mar 21, 2018, at 09:09, TJ Corona wrote: > >> Since no one appears to mind libraries with some source-dir overlap, maybe we could eliminate core and extensions at the top level and just have >> >> smtk/attribute/core >> smtk/model/{core, polygon, discrete, ...} >> smtk/mesh/{core, moab, vtk, pumi, ...} >> smtk/qt >> smtk/vtk >> smtk/paraview/{server, components, ...} >> >> and just make one library out of smtk/*/core. Or to be more consistent, >> >> smtk/core/{attribute, mesh, model, operation, resource} >> smtk/{discrete, mesh, polygon, ...}/{operators, environment, ...} >> smtk/{qt, paraview, python, vtk} > > >> On Mar 21, 2018, at 8:51 AM, David Thompson wrote: >> >>> I?m ok either though I tend to like keeping ?like? files close so having a json or pybind subdirectory in the same directory as the source file does remind you that you might need to make changes to them as well. >> >> I agree that's useful. It sounds like everyone's in agreement not to force separate directories for each library's source files -- at least for wrapping and serialization. >> >>> What about the stuff under bridge :) - should it be >>> >>> smtk/extension/session/polygon, >>> or >>> smtk/extension/modeler/polygon >>> or maybe >>> smtk/modeler/polygon? >> >> In my examples, I put it under extension/smtk/model/polygon so it would live in the smtk::model::polygon namespace. That eliminates the need for another namespace like kernel, session, or modeler. I would prefer to keep namespaces shallow and broad, however if you want to be more explicit at the top-level of SMTK's sources, we could split the extensions directory into different functional categories: >> >> modeler/smtk/model/polygon >> modeler/smtk/model/discrete >> >> mesher/smtk/mesh/triangle >> mesher/smtk/mesh/netgen >> >> gui/smtk/qt >> gui/smtk/paraview >> gui/smtk/vtk >> >> instead of just putting them all in extension/smtk/... >> >> Since no one appears to mind libraries with some source-dir overlap, maybe we could eliminate core and extensions at the top level and just have >> >> smtk/attribute/core >> smtk/model/{core, polygon, discrete, ...} >> smtk/mesh/{core, moab, vtk, pumi, ...} >> smtk/qt >> smtk/vtk >> smtk/paraview/{server, components, ...} >> >> and just make one library out of smtk/*/core. Or to be more consistent, >> >> smtk/core/{attribute, mesh, model, operation, resource} >> smtk/{discrete, mesh, polygon, ...}/{operators, environment, ...} >> smtk/{qt, paraview, python, vtk} >> >> would put all of smtkCore in smtk/core/* (along with its json, pybind, and environment libraries). That simplifies the directory layout a bit, but now what are the namespaces? Would we have smtk::core::model but smtk::polygon for the polygon session? I like keeping namespaces that correspond to directory trees. >> >> David >> >>>> On Mar 20, 2018, at 4:33 PM, David Thompson wrote: >>>> >>>>> I vote for putting them in the subdirectories of whatever source they wrap/serialize since each of them is associated with a specific file/class. >>>> >>>> I think TJ was hinting that we we do this: >>>> >>>>> core/json/smtk/{attribute, mesh, model}/jsonResource.{h,cxx} >>>>> core/pybind11/smtk/{attribute, mesh, model}/Py{Attribute, Mesh, Model}.cxx >>>>> >>>>> extension/json/smtk/{attribute, mesh, model}/jsonResource.{h,cxx} >>>>> extension/pybind11/smtk/{attribute, mesh, model}/Py{Attribute, Mesh, Model}.cxx >>>> >>>> then everything in core/smtk is in the smtkCore library; everything in the core/json directory could live in an smtkCoreJSON directory, etc. In general, the pattern would be that no two libraries have code in the same source directory. >>>> >>>> David >>>> _______________________________________________ >>>> Smtk-developers mailing list >>>> Smtk-developers at smtk.org >>>> https://smtk.org/mailman/listinfo/smtk-developers >>> >> >> _______________________________________________ >> Smtk-developers mailing list >> Smtk-developers at smtk.org >> https://smtk.org/mailman/listinfo/smtk-developers > From tj.corona at kitware.com Wed Mar 21 10:23:53 2018 From: tj.corona at kitware.com (TJ Corona) Date: Wed, 21 Mar 2018 10:23:53 -0400 Subject: [Smtk-developers] Pie in the sky In-Reply-To: References: <24D1A25C-34D0-47FC-83E7-CA7DED1E4259@kitware.com> <658F1E32-F868-4021-BC76-95B5ACDF201E@kitware.com> <765C17E2-C5D8-486E-965C-1A923DE0DEE6@kitware.com> <095344D5-3A59-4915-B20A-C4F673489B95@kitware.com> <0E2E3D80-3A3D-4C6B-8816-4B0340E45CA5@kitware.com> Message-ID: <4ACEAA38-8B98-4A77-AD7A-0290C46D7A5C@kitware.com> Ideally: smtkCommon, smtkResource, smtkAttribute, smtkModel, etc. Then we would know which parts of the code depend on other parts, and keep those dependencies in the right direction. I don?t know why vtk has a two-level system, but without a compelling reason to follow it I?d be just as happy to do our own thing. > On Mar 21, 2018, at 10:10 AM, David Thompson wrote: > >> We are still on the topic of pies in the sky, right? I would really, really like to see the smtk core library turn into something more granular. In addition to having smaller libraries, forcing developers to be mindful of directional dependencies would enforce better coding practices. While the directory structure neither helps nor hurts this goal, a good first step would be to remove core as a directory. > > If we follow the VTK practice and use a 2-level hierarchy, then > > + smtkCommonCore (what was smtk::common, the namespace would become smtk::core?), > + smtkCommonResource (smtk::resource), > + smtkCommonSystems (smtk::operation and smtk::attribute at a minimum ? they are codependent ? and perhaps smtk::model and smtk::mesh since it seems odd not to include them if we must include attribute), > + smtkQtCore, > + smtkPV{Server, Components, ...}, and > + smtkVTK{Source, IO, ...}. > > Is that what you had in mind? > > David > >> On Mar 21, 2018, at 09:09, TJ Corona wrote: >> >>> Since no one appears to mind libraries with some source-dir overlap, maybe we could eliminate core and extensions at the top level and just have >>> >>> smtk/attribute/core >>> smtk/model/{core, polygon, discrete, ...} >>> smtk/mesh/{core, moab, vtk, pumi, ...} >>> smtk/qt >>> smtk/vtk >>> smtk/paraview/{server, components, ...} >>> >>> and just make one library out of smtk/*/core. Or to be more consistent, >>> >>> smtk/core/{attribute, mesh, model, operation, resource} >>> smtk/{discrete, mesh, polygon, ...}/{operators, environment, ...} >>> smtk/{qt, paraview, python, vtk} >> >> >>> On Mar 21, 2018, at 8:51 AM, David Thompson wrote: >>> >>>> I?m ok either though I tend to like keeping ?like? files close so having a json or pybind subdirectory in the same directory as the source file does remind you that you might need to make changes to them as well. >>> >>> I agree that's useful. It sounds like everyone's in agreement not to force separate directories for each library's source files -- at least for wrapping and serialization. >>> >>>> What about the stuff under bridge :) - should it be >>>> >>>> smtk/extension/session/polygon, >>>> or >>>> smtk/extension/modeler/polygon >>>> or maybe >>>> smtk/modeler/polygon? >>> >>> In my examples, I put it under extension/smtk/model/polygon so it would live in the smtk::model::polygon namespace. That eliminates the need for another namespace like kernel, session, or modeler. I would prefer to keep namespaces shallow and broad, however if you want to be more explicit at the top-level of SMTK's sources, we could split the extensions directory into different functional categories: >>> >>> modeler/smtk/model/polygon >>> modeler/smtk/model/discrete >>> >>> mesher/smtk/mesh/triangle >>> mesher/smtk/mesh/netgen >>> >>> gui/smtk/qt >>> gui/smtk/paraview >>> gui/smtk/vtk >>> >>> instead of just putting them all in extension/smtk/... >>> >>> Since no one appears to mind libraries with some source-dir overlap, maybe we could eliminate core and extensions at the top level and just have >>> >>> smtk/attribute/core >>> smtk/model/{core, polygon, discrete, ...} >>> smtk/mesh/{core, moab, vtk, pumi, ...} >>> smtk/qt >>> smtk/vtk >>> smtk/paraview/{server, components, ...} >>> >>> and just make one library out of smtk/*/core. Or to be more consistent, >>> >>> smtk/core/{attribute, mesh, model, operation, resource} >>> smtk/{discrete, mesh, polygon, ...}/{operators, environment, ...} >>> smtk/{qt, paraview, python, vtk} >>> >>> would put all of smtkCore in smtk/core/* (along with its json, pybind, and environment libraries). That simplifies the directory layout a bit, but now what are the namespaces? Would we have smtk::core::model but smtk::polygon for the polygon session? I like keeping namespaces that correspond to directory trees. >>> >>> David >>> >>>>> On Mar 20, 2018, at 4:33 PM, David Thompson wrote: >>>>> >>>>>> I vote for putting them in the subdirectories of whatever source they wrap/serialize since each of them is associated with a specific file/class. >>>>> >>>>> I think TJ was hinting that we we do this: >>>>> >>>>>> core/json/smtk/{attribute, mesh, model}/jsonResource.{h,cxx} >>>>>> core/pybind11/smtk/{attribute, mesh, model}/Py{Attribute, Mesh, Model}.cxx >>>>>> >>>>>> extension/json/smtk/{attribute, mesh, model}/jsonResource.{h,cxx} >>>>>> extension/pybind11/smtk/{attribute, mesh, model}/Py{Attribute, Mesh, Model}.cxx >>>>> >>>>> then everything in core/smtk is in the smtkCore library; everything in the core/json directory could live in an smtkCoreJSON directory, etc. In general, the pattern would be that no two libraries have code in the same source directory. >>>>> >>>>> David >>>>> _______________________________________________ >>>>> Smtk-developers mailing list >>>>> Smtk-developers at smtk.org >>>>> https://smtk.org/mailman/listinfo/smtk-developers >>>> >>> >>> _______________________________________________ >>> Smtk-developers mailing list >>> Smtk-developers at smtk.org >>> https://smtk.org/mailman/listinfo/smtk-developers >> > From bob.obara at kitware.com Wed Mar 21 12:03:22 2018 From: bob.obara at kitware.com (Bob Obara) Date: Wed, 21 Mar 2018 12:03:22 -0400 Subject: [Smtk-developers] Change in Coding Convension Message-ID: <2059CFE9-330A-4C26-B4E3-AD5600A10291@kitware.com> Since all data members should be prefixed by a m_ - you no longer should be prefixing them by this-> . So to refer to a data member m_foo you should now only type m_foo instead of this->m_foo. I?ve fixed the master branch of smtk and have merged in the changes. Bob Robert M. O'Bara, MEng. Assistant Director of Scientific Computing Kitware Inc. 28 Corporate Drive Suite 101 Clifton Park, NY 12065 Phone: (518) 881- 4931 -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Wed Mar 21 15:35:53 2018 From: david.thompson at kitware.com (David Thompson) Date: Wed, 21 Mar 2018 15:35:53 -0400 Subject: [Smtk-developers] Pie in the sky In-Reply-To: <4ACEAA38-8B98-4A77-AD7A-0290C46D7A5C@kitware.com> References: <24D1A25C-34D0-47FC-83E7-CA7DED1E4259@kitware.com> <658F1E32-F868-4021-BC76-95B5ACDF201E@kitware.com> <765C17E2-C5D8-486E-965C-1A923DE0DEE6@kitware.com> <095344D5-3A59-4915-B20A-C4F673489B95@kitware.com> <0E2E3D80-3A3D-4C6B-8816-4B0340E45CA5@kitware.com> <4ACEAA38-8B98-4A77-AD7A-0290C46D7A5C@kitware.com> Message-ID: Hi TJ, > Ideally: smtkCommon, smtkResource, smtkAttribute, smtkModel, etc. Then we would know which parts of the code depend on other parts, and keep those dependencies in the right direction. If the attribute system moves to using operations to update values (which I believe it should), then smtkAttribute and smtkOperation cannot be separate libraries. > I don?t know why vtk has a two-level system, but without a compelling reason to follow it I?d be just as happy to do our own thing. To explicitly avoid more than 2 levels and to force everything to be at the leaves. A completely flat system was too cumbersome (VTK got too big to have vtkCommon, vtkRendering, etc., but that's the way it used to be). IIRC, there was talk of an arbitrary hierarchy but people (including me) objected as that makes it hard to remember where things live (which is an issue that I think makes SMTK less approachable and easy to use even now). Certainly, simplicity was a reason for VTK's pattern[1] and although there are many annoyances with the VTK module system, I appreciate the simple hierarchy. David [1]: https://blog.kitware.com/whats-new-in-vtk-6/ (see "Simple Module Naming Scheme") From tj.corona at kitware.com Wed Mar 21 15:59:21 2018 From: tj.corona at kitware.com (TJ Corona) Date: Wed, 21 Mar 2018 15:59:21 -0400 Subject: [Smtk-developers] Pie in the sky In-Reply-To: References: <24D1A25C-34D0-47FC-83E7-CA7DED1E4259@kitware.com> <658F1E32-F868-4021-BC76-95B5ACDF201E@kitware.com> <765C17E2-C5D8-486E-965C-1A923DE0DEE6@kitware.com> <095344D5-3A59-4915-B20A-C4F673489B95@kitware.com> <0E2E3D80-3A3D-4C6B-8816-4B0340E45CA5@kitware.com> <4ACEAA38-8B98-4A77-AD7A-0290C46D7A5C@kitware.com> Message-ID: > If the attribute system moves to using operations to update values (which I believe it should), then smtkAttribute and smtkOperation cannot be separate libraries. Currently, smtkAttribute has all of its IO in smtkIO. I agree that smtkOperation currently requires smtkAttribute (for now?), but the converse need not be true. > an issue that I think makes SMTK less approachable and easy to use even now Maybe. I see it a little differently. VTK imposes a monolithic style and a single workflow onto its developers. This is both a strength and a weakness. I see SMTK (in addition to being much more modern code) as having coherent sections that interplay. Each of these sections (model, mesh, attribute, etc.) have a completely different coding style, API, memory pattern (they just do. Nothing wrong with that), as they are designed to solve different problems. IMHO the best thing we can do is define their interplay in as clear and succinct a fashion as we can. That way, one section?s design does not conflict with another?s, and a developer need only understand SMTK one section at a time. At the per-section scope, as long as the API and underlying code patterns are clear, self-consistent and well documented, I?d call that a win. This laissez-faire approach gives us, the developers, the freedom to design a library that best satisfies the task at hand. The tradeoff (as you mentioned) is the intellectual burden of understanding each part of SMTK on an individual basis. If these sections can stand alone, then I believe that this burden is lessened significantly. > On Mar 21, 2018, at 3:35 PM, David Thompson wrote: > > Hi TJ, > >> Ideally: smtkCommon, smtkResource, smtkAttribute, smtkModel, etc. Then we would know which parts of the code depend on other parts, and keep those dependencies in the right direction. > > If the attribute system moves to using operations to update values (which I believe it should), then smtkAttribute and smtkOperation cannot be separate libraries. > >> I don?t know why vtk has a two-level system, but without a compelling reason to follow it I?d be just as happy to do our own thing. > > To explicitly avoid more than 2 levels and to force everything to be at the leaves. A completely flat system was too cumbersome (VTK got too big to have vtkCommon, vtkRendering, etc., but that's the way it used to be). IIRC, there was talk of an arbitrary hierarchy but people (including me) objected as that makes it hard to remember where things live (which is an issue that I think makes SMTK less approachable and easy to use even now). > > Certainly, simplicity was a reason for VTK's pattern[1] and although there are many annoyances with the VTK module system, I appreciate the simple hierarchy. > > David > > [1]: https://blog.kitware.com/whats-new-in-vtk-6/ (see "Simple Module Naming Scheme")