| 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!
_______________________________________________
hono-dev mailing list
hono-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/hono-dev