Rick,
I absolutely love the idea of a Metadata "discovery" mechanism. But I
think do this properly, we should - as you suggested - think out of the
protocol "box".
Let me start with a provoking idea:
Why
not use a RESTful approach for metadata discovery?
>From my point of view it doesn't make much sense to use Pub / Sub for a
discovery, because a concrete client decides itself when and how it
wants to discover metadata. There is no chance for the server to figure
out when a client wants to discover metadata of one or more topics.
Note, that this does *not* mean to use HTTP. I am just advocating for a
RESTful approach, be it HTTP, CoAP or a tiny custom binary "request -
response with GET and POST" protocol. I think the RESTful fits very well
to the MQTT Topic world. Let me explain this idea on a concrete
example. I am using HTTP REST notations for simplicity and to
demonstrate the idea. Also note that I am using a JSON format for better
readability for the metadata. JSON is not a format I propose for
metadata.
Discovery of Topic Metadata
----------------------------------------
1. Client 1 decides he wants to know what metadata he can expect on
topic "my/topic".
2. Client 1 requests mqttmetadata://localhost:80/my/topic with an GET
3. Server responds with a message {"metadataAvailable": true,
"metadataStructure": {.....STRUCTURE FORMAT...}};
4. Client 1 can generate the object parser for the topic dynamically /
prepare for the data he expects
5. Client 1 subscribes to mqtt://localhost:1883/my/topic
Discovery of Topic Metadata with # Wildcards
----------------------------------------
1. Client 1 decides he wants to know what metadata he can expect on
topic "my/topic/#".
2. Client 1 requests mqttmetadata://localhost:80/my/topic/# with an
GET
3. Server responds with a message {{"topic": "my/topic/A",
"metadata{metadataAvailable: true, metadataStructure: {.....STRUCTURE
FORMAT...}},......}};
4. Client 1 can generate the object parser for the topic dynamically /
prepare for the data he expects
5. Client 1 subscribes to mqtt://localhost:1883/my/topic/#
Discovery of Topic Metadata with + Wildcards
----------------------------------------
1. Client 1 decides he wants to know what metadata he can expect on
topic "my/+/A".
2. Client 1 requests mqttmetadata://localhost:80/my/+/A with an GET
3. Server responds with a message {{"topic": "my/topic/A",
"metadata{metadataAvailable: true, metadataStructure: {.....STRUCTURE
FORMAT...}},......}};
4. Client 1 can generate the object parser for the topic dynamically /
prepare for the data he expects
5. Client 1 subscribes to mqtt://localhost:1883/my/+/A
Discovery of all Metadata
----------------------------------------
1. Client 1 decides he wants to know all metadata on the MQTT broker.
2. Client 1 requests mqttmetadata://localhost:80/$metadata with an GET
3. Server responds with a message {{"topic": "my/topic/A",
"metadata{metadataAvailable: true, metadataStructure: {.....STRUCTURE
FORMAT...}},......}}; //Only topics which actually have metadata
4. Client 1 can generate the object parser for the topic dynamically /
prepare for the data he expects
5. Client 1 subscribes to the topic he desires
The advantages with such an approach would be:
- It would be easy to administrate the allowed topic metadata for
concrete topics on the broker
- If it is not desired to have structured data on a topic, the
metadata discovery would simply return that there is unstructured data.
- Discovery of all metadata is simple
- The server can validate incoming messages if they match the metadata
structure if desired
This example is far from perfect but I hope it's sufficient to get the
idea. I'd love to hear your thoughts.
Best,
Dominik
Rick Bullotta wrote: