| 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?
+1
Ok, then we should go for this approach. I will change the API description and code accordingly.
It’s a shame really, as hyphenated property names are used on so many places and are easiest to read. From these two options, underscores are a bit “more natural” and easier to read for message properties (device_id), but I don’t have any strong opinions or theories to back one approach over the other.
Yes, it’s annoying. We could also disable property validation at all (jms.validatePropertyNames), but I don’t know if this is possible with other clients..
So anyway, I prefer the underscore too and as there seem to be no other objections, I will change this in the APIs as discussed.
_______________________________________________
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
--
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