29 Apr
2015
29 Apr
'15
4:09 p.m.
Hi Peter,
Thanks a lot for your comprehensive answer!
I agree with your view on MQTT but from discussion I’m having not a lot of organisations
see federation as something that adds value and go for a short term win. You provide me
with some good arguments against that :-)
Perhaps it is. I would not mind participating.
That is sort of the approach I wanted to take for pubsub but did not link it to XEP-0324
yet. Thanks.
Something like that except I would use IoT events
(https://xmpp.org/extensions/inbox/iot-events.html
<https://xmpp.org/extensions/inbox/iot-events.html>) and let the ‘dealer’ optimise
the subscriptions towards the ‘Things’.
In the dealer pattern the client applications, that want to subscribe to sensor data from
the Things, instead subscribe to the dealer service. Once subscribed the clients receive
the measurements from all the Things via the dealer.
The dealer is responsible to subscribe to all the individual Things and when it receives
new measurements it will instantly publish these measurement to clients that subscribed to
the dealer.
Best regards,
Eelco
This message may contain information that is not intended for you. If you are not the
addressee or if this message was sent to you by mistake, you are requested to inform the
sender and delete the message. TNO accepts no liability for the content of this e-mail,
for the manner in which you use it and for damage of any kind resulting from the risks
inherent to the electronic transmission of messages.
2. There is
currently no best practises in using pubsub or PEP for IoT.
Perhaps it’s time to retake the XEP-writing effort and write down some guidelines for IoT
on XMPP using pubsub… 3. Management
of pubsub nodes (manage subscribers and publishers) is cumbersome and not all functions
(authorization schemes) are supported by all XMPP servers.
Some kind of minimum supported server pubsub functionality might be necessary, together
with a validation procedure. I know similar work is being done by UPnP to make sure XMPP
servers support a minimum set of functionality required. Much of the administration might
be taken care of if the server supports model “authorize” which allows node owners to
approve or deny subscriptions. The owner can tie this into provisioning (XEP-0324)
(canRead), for automated decisionmaking and a single interface for both momentary readouts
and publish/subscribe. 4. I proposed
an alternative pubsub like service, that I called ‘dealer’, which acts as a IoT
concentrator towards the subscribers and that would subscribe to all Things the clients
would want to receive events from.
Ok, not sure I understand. Please tell me more. Would it be an entity that subscribes to
data from multiple nodes, and then makes it accessible using XEP-326 to other interested
parties?