On Wed, Oct 7, 2015 at 1:55 PM, Thiago Macieira <thiago.macieira at intel.com> wrote: > On Wednesday 07 October 2015 11:01:48 Drasko DRASKOVIC wrote: >> Hi all, >> I can see here: >> https://github.com/iotivity/iotivity-xmpp/commits/master that there >> has been an effort to enable Iotiviry remote access via XMPP. >> >> Why did both AllJoyn and Iotivity choose XMPP to strat with? Would not >> some other protocol - like CoAP (and LwM2M) or MQTT, or even HTTP >> would be better starting point, in order to immidiately connect the >> Iotivity devices to existing cloud services like Xively or Bluemix? > > We can't speak for AllJoyn, so you'll have to ask them.
There must be something significant about this protocol, since both Alljoyn and Iotivity chosen this one. I thought that Aljjoyn choice comes from Affinity company, which used XMPP in previous products... > > Others can chime in, but I believe the rationale goes like this: > - HTTP: not bi-directional, so technically unsuitable for the task > - XMPP: known quantity > - CoAP, MQTT: unknown quantities in firewalls Maybe I misunderstood something... But big majority of already existing IoT clouds are using either MQTT or CoAP (they are using often HTTP or WebSocket, but this is more for user apps then for devices themselves). These (especialy coap) have suitable client libraries for constrained devices, Moreover, OMA-LWM2M i a standardized way for devices to reach coud over CoAP. If these cloud services are already implemented - why not reuse them. What does mean "known quantity" for XMPP? Would you say that CoAP or MQTT would not be well suited for this task because of intermediate firewalls? I do not see the problems with firewalls, as device behind firewall opens the connection to the cloud, and not the other way (cloud->device, although even this is realtively easy achiveable: https://lists.w3.org/Archives/Public/public-wot-ig/2015Sep/0023.html). I must be missing something, as XMPP choice comes as a surprise to me, so can you please point me to the discussions about making this coice in Iotiviry (if there are public ones). > > That pretty much settled the discussion. > >> Can anybody tell me the state of this GW and what other protocols are >> planned? > > None others are planned. What did you expect to see in our plans? What would > we gain from having other transports? Let people connect IoTivity networks to different cloud providers - for example ones that do not support XMPP (which is about 90%). I mentioned two very popular - Xively and IBM Bluemix. There must be a tons of them, as the vast majority of IoT clouds do not support XMPP, this is definitly not the choice of protocol for these clods today. We can see HTTP REST, WebSockets, MQTT and CoAP proliferate, but not XMPP. That's why I was surprised with your choice on XMPP. The only reason for XMPP that comes to my mind is TR-069 Amendment 5 (https://www.broadband-forum.org/cwmp.php), as a standardized way to manage WAN gatewaysm but this still do not justify the way you would export Iotivity services form the local network to the IoT cloud... BR, Drasko
