| Re: [hono-dev] Telemetry & Device Registration API |
to sum it up, links are created with a dedicated endpoint (e.g. telemetry/<tenantId>, anonymous relay is not supported), so we can check if a client is authorized to attach. Messages sent via the created link must contain a defined set of header fields e.g. <device-id>, <tenant-id> (details are specified in the respective endpoint api). Do you agree?
Kai and I had some further discussions on how to make the implementation more independent of the way this information is passed to Hono e.g. as header fields, in the ‘to’ property,... (as Dejan said there may be alternative approaches in the future). Our idea was to normalize the information into a defined set of message annotations that can be used to further process/route the message. What do you think about this? Another question in this regard is if the Qpid Dispatch Router is already or will be able to route messages depending on such message annotations?
And one final point: to support the JMS standard we cannot use dashes in properties (e.g. device-id). We could use camel case notation (deviceId) or underscores (device_id). Which one do you prefer?
Regards,
Dominik
From: hono-dev-bounces@xxxxxxxxxxx [mailto:hono-dev-bounces@xxxxxxxxxxx] On Behalf Of Dejan Bosanac
Sent: Wednesday, June 15, 2016 11:25 AM
To: hono developer discussions <hono-dev@xxxxxxxxxxx>
Subject: Re: [hono-dev] Telemetry & Device Registration API
Hi Kai,
I agree, introducing the properties is the easiest approach (and it’s clean). We can discuss adding other approaches later, if we ever feel a need for them.
On Tue, Jun 14, 2016 at 4:01 PM, Hudalla Kai (INST/ESY1) <Kai.Hudalla@xxxxxxxxxxxx> wrote:
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
--
Regards
--
Dejan Bosanac
about.me/dejanb
_______________________________________________
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