[OASIS Issue Tracker] (MQTT-264) Broadcast publish

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/MQTT-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=59757#comment-59757 ] 

Andrew Banks commented on MQTT-264:
-----------------------------------

The use cases where META topics can be used will be constrained to where the metadata changes slowly and is updated by an administrator, this stems from there being only one retained message associated with a topic. It would not be possible to have per message or per client metadata.

So for example an administrator setting the metadata to say TimeToLive for all messages published on the topic is 10 seconds would be fine.
However a client application publishing a metadata message on the same topic would not be fine because another client might simultaneously be 
setting the TimeToLive to a different value.

It would be difficult to write a reliable application that set the metadata for a single message using a unique topic name. 
The client application would have to first publish the retained message containing the metadata. After the payload message  is published
the client would have to publish a null retained metadata message to clear the first retained message. If the client does not 
complete this sequence then there is a risk that there will be a buildup of the metadata messages.  



> Broadcast publish
> -----------------
>
>                 Key: MQTT-264
>                 URL: https://issues.oasis-open.org/browse/MQTT-264
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: New Feature
>          Components: futures
>    Affects Versions: 3.1.1
>            Reporter: Andrew Schofield
>             Fix For: 3.1.1
>
>
> One of the proposals for message format indications suggests a kind of convention using a parallel metadata topic tree. For example, a retained message on topic "$META/Fruit/Apples" could be used to indicate the format of messages on topic "Fruit/Apples". A client wishing to publish or subscribe on "Fruit/Apples" could first make a subscription on "$META/Fruit/Apples" to discover the message format. Using the existing pub/sub rules is inconvenient in this case.
> If I want to use the same message format information for all fruity topics, I don't want to publish separate messages on each of "$META/Fruit/Apples", "$META/Fruit/Mangoes" and so on. If I publish on "$META/Fruit", it would not be sufficient to subscribe to "$META/Fruit/Apples" to discover the message format. What I want is a way to publish a message for all fruits.
> Another example comes from the IoT domain. Let's say that I have connected lights subscribing to "lights/<light-id>/off" and each light turns off when it receives a message to its topic. If I want to turn off all lights at once, I could define another topic "lights/alloff" and get each light to make a second subscription. Alternatively, I could publish one message to all lights.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)