Skip to main content

[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

[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.

Back to the top