In this reply, I’ll be looking at the following questions raised by the original post:
- Should Speckle clients support multiple kits at once?
- When sending, how should the kit be selected?
- Should the CoreGeometry and Elements kits be merged?
- When receiving, how should kits be selected?
I agree that the current method of somewhat randomly choosing a kit to convert Native Objects (NO) into SpeckleObjects (SO) needs to be made deterministic.
My understanding of the proposal is that by limiting each user to selecting a single active SpeckleKit at a time (system-wide!), we can ensure explicit converter selection.
There are situations alreay where explicit conversion happens, namely in the Schema Building Component in Grasshopper. No changes are required to this use case to get deterministic conversion.
To phase this as a question: when sending a group of objects (e.g. from Rhino or Revit), should SpeckleKits be chosen on a system-wide basis, a per-stream basis, or a per-object basis?
Selecting a single Kit on a system-wide basis will lead to a very frustrating user experience. People who are using different kits on different projects, or who are using multiple kits on a single project will spend a lot of time going into their system-wide settings and changing their active kit. As Hugh mentioned above, it would be great to avoid human error by locking the kit seletion in on a project or file basis.
Selecting a Kit on a per-object basis will also give a terrible user experience, because, well, selecting the kit for every single object is a lot of work… (that’s a lot of pop ups!) I only mention this option so that we can dismiss it.
So it seems to makes sense to select a Kit on a per-stream basis. I suggest that when a stream is created, the user be asked to select a primary Kit for conversions, and also specify if they want to also use CoreGeometry to convert elements that the primary kit cannot convert. The UI might look something like this:
This gives the following advantages:
- The CoreGeometry and Elements kit do not need to be merged. Basing new kits on the CoreGeometry objects is Speckle’s interoperability secret sauce, and tightly coupling CoreGeometry and Elements is not ideal. (see below)
- This gives any kit the ability to “merge” with CoreGeometry, instead of just the Elements kit.
- Once a stream has been set up, the user does not need to remember what Kit was chosen.
- Default kits can still be chosen by the client or set on a system-wide basis, so that new users don’t have to learn about it to get started.
- Different kits can be chosen for different projects, or different steps of the design process. (e.g. a façade designer might want to use the Elements kit to send some objects to the architect, and the Strutural kit to send them to the strutural engineer).
Merging CoreGeometry and Elements
Picking up the first point, the next question is: “Should the CoreGeometry and Elements” kits be merged?
Keeping the kits separate will help the Speckle ecosystem stay away from slow, IFC-like discussions about what the Kit should be. CoreGeometry provides a common vocabulary to specify geometry for the whole Speckle ecosystem, and keeping it purely focused on geometry encourages a federated, flexible approach to object model definitions.
We might rename the existing Kits as follows:
Some new kits we might see developed:
For the sake of easy coordination, having all the geometric objects in each kit inherit from the CoreGeometry classes makes it easy to create a federated model for coordination, issue tracking and clash detection, while giving freedom to smaller groups to define and refine their object models.
Choosing a kit when receiving
If we follow the suggestions above regarding sending streams, we will have two types of stream to deal with on reception:
- Streams where all the objects are from a given kit or CoreGeometry
- Streams that have been created by a script (GH, Dynamo, python, etc…) where there is no guarantee regarding the number of Kits used.
A simple and robust way to deal with all this is to expand the
type definition of SpeckleObjects to specify the Kit name and version for each type. For example, a column in Speckle 1.0 has the following type:
in Speckle 2.0, this could be:
By specifying this information on a per-object basis, we acheive a deterministic converter selection, and maintain the benefits of specifying a chain of types for a given object. In fact, this gives clients the option of either looking into the type themselves and picking a kit, or just passing the objects to SpeckleCore. Either option will give a deterministic conversion.
As an added bonus, clients won’t need to load kits unless they actually need them for a particular object, so bugs in one kit (cough, cough, SpeckleStructural) won’t crash clients that never use them :).
(As an aside, though we could in theory have long type chains, I suspect that two types–a primary type, and a CoreGeometry type–will be enough for almost all use cases. I would love to hear what others think.)
To summarize all this, here are the 4 questions I listed at the top, with our suggestions:
- Should Speckle clients support multiple kits at once? Yes. Allow users to select a Kit when creating a stream.
- When sending, how should the kit be selected? On a per-stream basis, with optional fallback to Core Geometry.
- Should the CoreGeometry and Elements kits be merged? No
- When receiving, how should kits be selected? Specify the Kit, version and object name in each object, and select a converter on that basis.
I have framed my comments around specific questions in the hope that it will make it easier for everyone to engage with the specific topics. Please share your opinions!!