You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Middleware runs on a single task, by design. It's not our business to spin tasks on behalf of the device application, since we want to help OEMs save every last byte. Because of this model we also are not thread safe.
That said we've received a few requests along the lines of "Suppose I want a Thermostat Agent and a Device Update Agent on the same underlying FreeRTOS az_iot_hub handle?" We need a definitive answer here, which will be some mix of clear documentation and samples at minimum. PnP and its componentization model naturally lends a shape to (de)multiplexing.
We may consider some level of a convenience API to make this easier. (We're NOT looking to one-for-one re-create the convenience layer of Azure IoT C SDK at present in the middleware, however, due to the extra complexity this would add. But if there's something that would be optional only for people wanting this and that could be supported by SDK and not overly complex, we'll consider.)
The text was updated successfully, but these errors were encountered:
jspaith
changed the title
Document multiple agent/component models
Document multiple agent/component models, consider helpers
May 18, 2021
The Middleware runs on a single task, by design. It's not our business to spin tasks on behalf of the device application, since we want to help OEMs save every last byte. Because of this model we also are not thread safe.
That said we've received a few requests along the lines of "Suppose I want a Thermostat Agent and a Device Update Agent on the same underlying FreeRTOS az_iot_hub handle?" We need a definitive answer here, which will be some mix of clear documentation and samples at minimum. PnP and its componentization model naturally lends a shape to (de)multiplexing.
We may consider some level of a convenience API to make this easier. (We're NOT looking to one-for-one re-create the convenience layer of Azure IoT C SDK at present in the middleware, however, due to the extra complexity this would add. But if there's something that would be optional only for people wanting this and that could be supported by SDK and not overly complex, we'll consider.)
The text was updated successfully, but these errors were encountered: