There should be a base "state control" interface and an interface defining a list of these interfaces

[TrevorPayne]

As Essentials matures and the intent is for more "pure" essentials systems to be deployed in the wild, we need to have some more primitive interfaces to provide interoperability between plugins.

One that jumps out as me as both super important, and puzzling as to why it isn't there as of yet, is a series of "state control" interfaces that defines a bool, a set method, a toggle method, an event, a name, and a key alongside a second interface that provides a collection of these controls. This can be multiple methods that build upon each other, but the main issue is that sending more primitive data between plugins is currently more difficult than it needs to be.

Imagine you have a GlobalCache device that we build a plugin for that is a contact closure. We need to get that contact closure data from the device, and it needs to be accessible to a plugin that triggers an action based on the contact closure...

but suppose we also need it to trigger based on the state of a mute on a DSP - ok, so now we need to be able to track a IHasMute and some other interface as well. What about also needing to know a call is in progress to trigger it...

Yes, we can use a connector plugin to tie all of these together sure, and you may still with my proposal, but if all of those things had the option to track a more "generalized" state rather than a specific state for the rare instance that we just need a dumb trigger....or you could even have a connector plugin that says "alright, a HookState and a MuteState and a ContactState can all be represented by this other interface we've already defined as GeneralState.

I understand we currently have some interfaces that "technically" accomplish this (IHasMute, for example), those are not generalized enough and while they could be made to work, continued utilization of interfaces defined as IHasMute for things like a logic state from a sensor device would be problematic for the sake of documentation.

I feel like this would likely facilitate some refactoring of other interfaces that currently contain these base types already (such as the aforementioned IHasMute) and that may cause some short-term consternation as things are appropriately aligned, but it's likely a long-term winner.