Hey all,
we had a look at it ~ 2 ys ago. This was the result:
-
Proprietary protocol. (no MQTT, no AMQP)
-
No persistence layer as yet.
-
In-memory signaling technology rather than a message broker.
-
Could be used for telemetry use cases, if “spray and pray” mode is sufficient, but won’t help with command/control.
Looks like they added a new component ”NATS Streaming” in the meantime, that adds at least the persistence part and could support more reliable command/control.
AFAIU, NATS doesn´t provide higher-level concepts like “tenants”, “telemetry”, “command&control” and “device registration, it remains at messaging and event-processing
level, “only”. So, I wouldn´t regard it as a competitive technology to Hono. Also, because there currently is nothing comparable to device connectivity adapters (CoAP, LWM2M), which are at least planned to be implemented at some point in time to my understanding.
WDYT?
J
Cheers, Caro
Von: hono-dev-bounces@xxxxxxxxxxx [mailto:hono-dev-bounces@xxxxxxxxxxx]
Im Auftrag von Benjamin Cabé
Gesendet: Mittwoch, 14. März 2018 23:30
An: hono developer discussions <hono-dev@xxxxxxxxxxx>
Betreff: [hono-dev] NATS vs. Eclipse hono
Hi there,
I would be interested in hearing how people think it compares to (or competes with?) hono.