Managing multiple Kits

Help
1

Hi Speckle team!

Another question :smile:

What are people thinking when it comes to managing multiple Kits? We’re starting to look at writing a new structural schema now, along with thinking about a v2 GSA connector, so we’re wondering how we can best approach handling things like Kits selection, easy swapping between Kits and specifying a hierarchy or order to Kits (ex. automatically defaulting to a specific Kit A instead a Kit B for a specific connector).

Excited to hear your thoughts!

Looping in @stam too!

Thanks!
Jenessa

2

Hi again!

Core and all our connectors have been developed with support for multiple kits, although at the moment only Grasshopper exposes a UI to swap between them - this is simply because there hasn’t been a need yet!

Kits in v2 behave differently than in v1, and while in v1 they complemented each other, in v2 kits “replace” each other. As a user, when sending data, you should be aware of what kit has been selected. When receiving instead, we could automate kit selection based on the content of the commit (this logic doesn’t exist yet).

So I’d definitely suggest adding structural classes and conversions to Objects, if possible, instead of creating a new kit.

I’d also like to loop in @MdeLeur @JdB @pieter who mentioned developing structural classes in the past too!

2 Likes
3

@teocomi thank you for the tag!

Good to invite @Rob as well, since he is is looking into the conversion of our structural objects to Speckle V2 objects.

1 Like
4

Ahh gotcha, thanks for clarifying @teocomi! What types of schemas do you see not fitting in Objects?

Thanks also for looping in the community! @MdeLeur, @JdB, @pieter and @Rob - it’d be awesome to do a deeper dive into the structural schema, perhaps through a quick workshop? Would you guys have any time in the next couple weeks? I can reach out offline to set up an meeting invite :smile:

5

Hi @jenessa.man we don’t see any particular schemas not fitting into Objects, it’s rather the case of companies/developers that might find Objects unfit to their needs. Let me untangle that sentence by saying the main use cases I see for a custom kit:

  • IP retention: company/person X doesn’t want to add their precious classes and conversion to an open source project
  • conflicts: company/person Y wants to structure data or have conversion routines behave in a way which substantially conflicts with how Objects does things
  • specific use: company/person Z wants to add classes and conversions that are specific to them only, or to a specific project

Hope it makes sense!

6

That makes sense, thanks @teocomi!