Speckle kit not required for custom classes

Hi all,

I was reading the discussion on Introducing Kits 2.0. The referenced post of @dimitrie on un-conversion is relevant for us. As the topic is closed, I hope it’s fine that I open this topic to address my question.

Especially this quote is interesting to me.

If the original class is not present, we fall back on the base speckle object class, and store the props as dynamic props.

So if I understand well, conversion of a Speckle object of a custom class can still be performed if a Speckle kit is not defined for that class. In that case a generic conversion of the base class is performed?

To also provide some background information, we have a Python package partly based on PySpeckle. With this package we can setup FEM models and exchange them with different FEM applications. We’re connecting this package to Speckle, to also exchange data to Revit, Grasshopper, etc. Lately we created some functionality that dynamically creates Speckle classes at runtime based on our own specific FEM classes, for example material models. These are objects that are mostly irrelevant for other clients. Sending and receiving streams in this way works perfectly fine with our own Python package. However, if we want to receive such stream in another client (Revit, Grasshopper, Dynamo), currently it gets stuck as there are no Speckle kits defined for these classes. Therefore, coming back to my question, it would be perfect for us if in Speckle 2.0, conversion of these classes is executed in a generic way. Then we don’t need to create Speckle kits for classes that aren’t used in the concerning clients anyway.

Bit of a long story, but I hope it’s clear.
Thanks in advance!

1 Like

Hey @Rob, sure! That topic got locked so as to encourage unpacking the topics in there a bit more, so totally cool re new topic.

Long story short, it’s a “yes” to your question. If I receive an object that’s defined in your special kit, that I don’t have access to, it will be deserialized to a Base object. We’ve tried getting a bit of that pyhon/js flexibility into c#.

In desktop-ui bound clients, ie revit, rhino, etc. these objects won’t show up, but in dynamo and grasshopper you’ll be able to unpack them and still do stuff with their data down the line.

1 Like

Great! That’s a real benefit for us.
Big improvement of the flexibility at our side.
Looking forward to the release :smile:

Thanks for the quick reply!