[Smtk-developers] Pie in the sky

[TJ Corona]

> 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 <david.thompson at kitware.com> 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")