[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [hono-dev] Agenda for face-to-face meeting
|
On 01/04/16 09:51, Hudalla Kai (INST/ESY) wrote:
-----Ursprüngliche Nachricht-----
Von: hono-dev-bounces@xxxxxxxxxxx [mailto:hono-dev-bounces@xxxxxxxxxxx] Im
Auftrag von Gordon Sim
Gesendet: Donnerstag, 31. März 2016 19:29
An: hono-dev@xxxxxxxxxxx
Betreff: Re: [hono-dev] Agenda for face-to-face meeting
[...]
* Might it be worth recommending use of the subject property on an AMQP
message where appropriate. (E.g. an MQTT protocol adapter might use that to
hold the original MQTT topic, a CoAP or REST adapter might use it to hold the
resource identifier)? That then provides a basic uniform way to do logical
classification.
[KH] I am not sure if I understand what you mean by "logical classification". I do not really see (yet) why Hono would be interested in classifying the data based on the technical means it has originally been transmitted. After all, Hono's main purpose is to actually abstract away these technical details. However, a client can include any properties in the telemetry messages it wants to and Hono will forward them to the consumer *as is*. So, if a consumer can/wants to make use of such information it is free to do so.
That was probably a poor choice of term on my part.
What I mean is that there is some semantic information often implied in
the MQTT topic or in the resource identifiers for REST. Retaining that
information across the protocol transition is valuable. Having a common
recommended approach to doing so would also be valuable.
The point is not that the subject describes the protocol the event was
published over, but that it retains something that may be a meaningful
classification, and that it does so through a standard property.
My thought was not to mandate the use of subject nor to tightly define
what it means (which I don't think would be possible) but to recommend
that the subject be used in the first instance for any information
retained from the original event that does not have an explicit mapping
defined in the telemetry spec.
