If the
perception is that oBIX 1.1 requires large processors and
memory, then we need to (a) confirm that is not the case,
then (b) decide how to evangelize that to the market. It
could just be that is the propaganda being put out by the
people who stand to gain by users choosing a different
approach than oBIX. It could be that because the main
implementation of oBIX is Niagara AX, which typically runs
on fairly beefy hardware, people assume that is the only way
oBIX can be done. But we’ve done an implementation that
runs in around 100KB, which uses oBIX (binary encoding) for
reading and writing values. It’s a limited form of oBIX,
but certainly disproves the notion that oBIX 1.1 requires a
larger machine.
Craig
Some feedback
from the HayStack conference was that being compliant with
oBIX 1.1 was going to require large processors and memory.
Without descending into whether that is or is not true, and
without pondering what these thoughts not raised in comments
are based on, It is a real perception.
I am personally
frustrated with oBIX, always have been, because it does not
support tome of the queries similar to those I posited in my
last post. On the other hand, we need to make it clearly
unambiguous that a simple service exposing a handful of oBIX
points can be compliant on the smallest system.
tc
"When one
door closes, another opens; but we often look so long and
so regretfully upon the closed door that we do not see the
one which has opened for us."
-- Alexander Graham Bell