History Push, XMPP, Long Polling

[Brian Frank <brian.tridium@gmail.com>]

I have had a couple conversations with various people about how oBIX should deal with lack of bi-directional connectivity.  I want to formally capture some of the various ideas in an email to the group at large.

The first idea is that it would be nice to have a standard contract for pushing history data from a device in the field up to a server in the sky.  The existing contracts for history are structured for a server to poll a device for history data.  But if the device has no well known IP address, it would be nice to configure the system to push its history data on an interval basis.  There are various levels of sophistication to achieve this.  Some associated use cases:

  - does a history have to be pre-created on server in order to device to push data?

  - is there a hand-shake for the device to ask the server what data it already has to establish what data needs to get pushed?

  - does oBIX standardize the contracts used to how to configure a history for push?

The simplest thing we could do that would work would be to mimic what some vendors do today by just FTPing raw data to a server.  In this case the contract might look something like this:

  <obj href=""obix:HistorySink">

      <op name="sink" in="obix:HistorySinkIn">

  </obj>

  <obj href=""obix:HistorySinkIn">

     <list name="data" of="obix:HistoryRecord"/>

  </obj>

This would provide for a URL (of the sink op) to push a list of HistoryRecord items.  The HistorySink contract could be mixed in with the History contract to provide start/end timestamps.  I think this is the simplest thing that could work.  So I would like to discuss this approach on our call Wed.

Some other ideas generated from discussing this problem...

One of the fundamental problems here is the notion of bi-directional connectivity.  Problems like this arise b/c of difficult IT departments or network topologies where only the server has a well known IP address.  This isn't just a problem with history data synchronization, but is a general problem for alarming, real-time data, watches, etc.  One potential solution for the generic problem might be to standardize an alternate transport for oBIX besides HTTP which would allow one side of a connection to establish a TCP connection which would then enable peer-to-peer communications.  The protocol which would seem the best fit for this is XMPP.  So that is another idea we might wish to discuss.

Lastly, one issue which was raised earlier this week was using oBIX in a "long poll" mode.  In this mode, when a client polls for changes to a watch, if no changes are available the server doesn't immediately respond but rather holds open the TCP connection.  See http://en.wikipedia.org/wiki/Push_technology#Long_polling for details.  I believe vendors could choose to implement this today if they wish.  But if there is a desire we could standardize it as part of the specification.

So some ideas to noodle on before our call on Wed.

Brian