Resource Defs are the only SM primitive that points to data outside of the sensemaker, or in other words, they are the only primitives coupled to an applet happ bundle. All the other primitives (dimensions, methods, contexts, etc) defined in an applet config have no current use-case requiring them to declare from which applet they were defined.
This separation of concern makes me wonder if we should separate these logically so that there are two separate processes that take place when handling an applet config (or perhaps the concept of applet config is split into something like resource config and additional sensemaker primitives).
Another reason for this separation is that I can imagine scenarios where new non-resource def primitives would be defined and registered outside of an applet bundle and it's registration to the sensemaker. Which makes me think we need a more generic abstraction for adding these kinds of primitives (sometimes of which they are bundled with an applet).
Ideally, an "applet" (or more functionally, a UI that performs operations on and displays a set of resources) can make use of all the existing primitives in the Neighbourhood, so we need an abstraction that has a looser coupling between these primitives and the resource definitions.
Resource Defs are the only SM primitive that points to data outside of the sensemaker, or in other words, they are the only primitives coupled to an applet
happbundle. All the other primitives (dimensions, methods, contexts, etc) defined in an applet config have no current use-case requiring them to declare from which applet they were defined.This separation of concern makes me wonder if we should separate these logically so that there are two separate processes that take place when handling an applet config (or perhaps the concept of applet config is split into something like
resource configandadditional sensemaker primitives).Another reason for this separation is that I can imagine scenarios where new non-resource def primitives would be defined and registered outside of an applet bundle and it's registration to the sensemaker. Which makes me think we need a more generic abstraction for adding these kinds of primitives (sometimes of which they are bundled with an applet).
Ideally, an "applet" (or more functionally, a UI that performs operations on and displays a set of resources) can make use of all the existing primitives in the Neighbourhood, so we need an abstraction that has a looser coupling between these primitives and the resource definitions.