| Re: [hono-dev] Telemetry & Device Registration API |
Hi,
see my comments below ...
On Mi, 2016-06-08 at 13:22 +0000, Guggemos Dominik (INST/ECS1) wrote:
> Hi,
>
> I'm not entirely convinced yet. We are creating an AMQP API and I'm
> not sure if it's a good idea to align our API to the peculiarities of
> a single client (in this case the Qpid JMS Client). I think in the
> first place we should provide a clean AMQP API design (independent of
> implementations) and then add alternatives for clients if required.
In general, I agree with you. However, we are not aligning to a single
client but to a whole class of clients because it is the JMS spec that
prevents "address-per-message" when creating a producer for a "non-
null" destination. This problem exists for all JMS clients.
> Perhaps this can be combined with the policy-based approach Dejan
> suggested, which could mean that the JMS Client only supports the
> medium and loose policy? What I would like to avoid is that all
> clients have to go the JMS way just because the JMS client has some
> restrictions.
That sounds reasonable. However, this will have a major impact on our
current telemetry implementation because we currently delegate the
handling of ProtonReceivers to Endpoint implementations based on the
Link's target address (NOT the message's "to" field).
We can also fall back to using dedicated "device-id" and "tenant-id"
message properties again and require clients to create a link to a
dedicated endpoint (instead of the anonymous relay).
This would let us keep the current concept of delegating Receivers to
Endpoints ...
>
> Apart from that, do you think we should go for the policy approach in
> our first milestone or implement one of the policies mentioned and
> extend it in future milestones? If we choose the latter which
> "policy" should we implement now? I'm asking this because I'm stuck
> implementing this currently, see [1]
>
> [1] https://github.com/eclipse/hono/issues/7
I would actually prefer to start with the strict option in combination
with "tenant-id" and "device-id" properties ...
_______________________________________________
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