[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [hono-dev] Topology options for client connectivity
|
> You would also need some way to have Hono be able to indicate to the
> 'clients' (i.e. protocol adapters and solutions) if authorisation fails
> (i.e. you need to be able to signal to some extent in both directions).
>
Exactly, we would basically re-implement the link establishment process on top of established links using AMQP 1.0 messages ... feels kinda strange to me.
> > It seems to me that this approach would not require a dedicated
> "signaling queue/resource" as described above but would enable Hono to
> dynamically react to a client's Link establishment request, right?
>
> That is correct, yes. From Hono's perspective, the link establishment
> in this approach would be the same as if the client had connected
> directly to Hono.
>
This looks more appealing to me at least.
> > However, this might also be possible by plugging in to a broker to
> achieve the same thing but I am not an expert with the brokers under
> discussion (e.g. ActiveMQ, RabbitMQ).
>
> I am not an expert either, but for those two brokers at least I very
> much doubt it.
And even if this were possible it would basically mean that we need to deploy a broker specific version of Hono to a broker which doesn't feel right to me.
So, to me the main question is whether we want to "afford the luxury" of using a dedicated signaling resource/queue or instead want to be able to control link establishment and thus directly leverage the information exchanged as part of the link establishment process.
Personally, I am much in favor of the latter because it seems to have the potential of providing a cleaner API that doesn't rely on separate sequential message exchanges to get data flowing.
