Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [hono-dev] Let's get started

On 25/02/16 11:03, Hudalla Kai (INST/ESY1) wrote:
Of course, that should always be possible. But isn’t that a given if we
agree to expose Hono’s (messaging) interface using AMQP 1.0? I mean, an
AMQP 1.0 client can send any message it would send to Hono also to
generic AMQP 1.0 message broker, can’t it? The result of sending that
message might be different though, depending on what the consumer of
that message does with it, right?

To me, the value of hono is in the semantics that can be relied on. These are higher level semantics than a generic messaging infrastructure.

So e.g. with authorization, perhaps you want to raise the level of abstraction and deal with devices rather than messaging addresses (i.e. who can see events from this device or this category of device, who can invoke commands on it etc rather than who can send or receive on a given topic). In my view it is by raising the abstraction like this, in providing semantics targeted at the more specific use case, that hono will be successful.

Making it pluggable and/or allowing flexibility in how it is assembled/deployed is great, but I think you should ideally always be able to rely on the same semantics.

As far as is possible, cleanly separating concerns is of course desirable. It is always easier to co-locate components that were designed to be able to run as independent processes than to prise apart something that was built from the start to only run in-process.

Just my 2 cents of course!

Back to the top