Introducing Structural Classes for Speckle!

Hi @daviddekoning, @Reynold_Chan,

Thanks for clarifying the intentions; we aim to (over time) have everything in the purple layer as an agreed schema and we are only to write conversion routines to/from the purple layer - sounds good.

I appreciate the need for a green “temporary” layer where developers can dump their stuff when they are under time pressure, or when trying to implement things like materials (where there is pretty much a different schema for each program :face_with_raised_eyebrow:).

I do not understand why some items shouldn’t be allowed to go straight into the purple layer. We can still make proposals here for the community to discuss - I mean the proposals will always go into a pull request first so the code can still be discussed… :slight_smile: Some contributors may not be in a time-rush and only want to write their conversion routines once and not come back in, say, March to add the few missing items that weren’t already in purple. As @tlmn said, why are we making limitations to ourselves, there is already enough of that in AEC :laughing: - shouldn’t this be flexible for both cases?

And in the case of section profiles that we were discussing above, in my view, this is purely expanding on the existing schema, not making any changes. I’m happy to discuss the naming of things, to me also “Stadium” doesn’t make sense until you see the profile. And all of these AdSec specific profile types are typical in the construction industry.

What do you suggest as a guideline for writing conversion routines for (temporary) stuff in the green layer? As an example, can I write a conversion now between my AdSec.Profile.Stadium object to Speckle.Objects.Structural.AdSec.Properties.Profiles.Stadium object and then expect this to be an easy rename of the namespace when we agree to add my green layer-specific object to purple? Or will I have to rewrite it (thus I’d rather wait)?

1 Like