Many thanks for your interest in our project! New contributors are more than welcome.
1. Is Hono focused on
- building an IoT server that securely flows messages and execute workload
- or codifying client payload patterns that can be understood as generically actionable on north and southbound clients. IE – heres a payload that means we want to update our firmware with the attached binary
For us (Red Hat) the more interested is a second point which is really creating an API for IoT backend services. IMHO we should also avoid single "server" in the backend, rather create an AMQP-based API and services implementation that can be consumed using that API.
2. Will Hono allow multiple applications to run at once in isolation(Co-tenanted, or like Tomcat hosting many Web Applications at once) - I think the answer is yes, and it looks like they are called “Solutions”?
I believe that at some point that would be a requirement to have Hono multi-tenant-friendly.
3. What does the schema / meta-model of a “Solution” look like?
Solution is really any backend service connected to IoT connector and consuming some API from it. So your solution services should use Hono AMQP public API (which will be designed soon).
4. I see interesting thoughts about topic level ACL define applied to users and devices. Is the user/device registry intended to be extensible or injectable to third party solutions and auth strategies?
By all means. Our device management services will be pluggable when we will finally have those implemented :) .
5. Is there persistent or at-rest data storage in this design? Maybe something like a session or state
Do you mean something like temporary device data hold in some distributed data grid (like Hazelcast or Infinispan)? Or some database-like persistence API?
Cheers!
