We at GE (Digital) have started to look into hono more actively now. After going through the initial contribution and github issues and wiki, I would like to post my comments/questions on this forum to begin our involvement.
1) After going through excellent wiki page on topology options, I feel that the option of "connection via Message broker" is more closely aligned with what we are internally discussing at GE. Some reasons behind this are as follows:
a. Reduces one additional network hop
b. Avoids one additional protocol conversion if underlying MOM/broker being used doesn't natively support AMQP 1.0 (e.g. Kafka)
2) I understand from recent emails on this topic that "Connection via embedded/dedicated router" seems to be more popular. Would this preclude us from using "Connection via Message broker"?
3) We are looking at providing uniform interface to protocol adapters and solutions and provide multiple implementations for it based on underlying MOM/broker. We are looking at hono as that interface.
4) Based on my understanding of initial code contribution it appears that EventDispatcher is responsible for extracting messages from IN exchange and publish it on OUT exchange after applying ACLs. Why do we need an additional component to achieve authorization if underlying MOM can provide the same?
a. I am also expecting hono to provide a uniform authorization APIs with specific implementations to translate that abstraction directly to native MOM/broker constructs. Is this one of the objectives of hono or is the expectation that EventDispatcher will be the way to enforce authorization?
5) I also did not see any multi-tenant support (although I did read some posts regarding the same) as part of initial API. Is multi-tenancy support being considered as part of API design for the first milestone?
We are looking forward to more active involvement in coming weeks.
Thanks,
