Paul,
I do not know how others would imagine doing this, but I thought a bit
about how that could be useful to me. My imagination is that I I would
set up the polling via the comm channel so I can add, list or remove
polling tasks.
I would have the program sleeping on input from the channel with a
timeout. When I get a message, I decode what it is saying, decide what
to do, then come around to sleep again.
I would not think it would be useful/good to use the same channel to do
regular bus communications, the whole idea is to leave this in sleep
unless something useful happens. I can connect to owserver in parallel
to do the regular work.
Now comes the question of what types of things to poll for:
coming and going of devices, either all or by family
events from binary inputs, by all, family or device
min/max thresholds on value things
The final question in my mind is about polling interval. One way to look
at this is how often the polling is done. Another way to look at it is
what percentage of bus time should be spent on polling vs. reserved for
other work. I would tend to be more likely to use the latter, poll as
fast as you can but leave x% of the bus bandwidth available of other
traffic. That way I never shoot myself in the foot by asking for too
much polling. I do not have an intuitive sense of what kinds of polling
would product what amount of bus demand.
happy holidays,
jerry
On 12/22/2012 07:29 AM, Paul Alfille wrote:
Very thoughtful note.
Let me explore one of your ideas, on polling.
On Fri, Dec 21, 2012 at 6:06 PM, Michael Markstaller <m...@elabnet.de
<mailto:m...@elabnet.de>> wrote:
And then I thought, if it wouldn't be great for owserver to have some
kind of long-polling API where the client only gets notified if
something interesting (again: iButtons, IO's) has changed instead of
polling every 100ms.. Though I have no idea if/how this could be
implemented..
During the next days I wanted to add some timestamp-output to
debugging
to find out where we loose these 1-3secs but maybe there is an easier
way/thought..
The only way owserver could notify you of changes, is indeed to poll,
every so often.
One method would be to add that function into owserver, as you suggest.
Another way would be to create an "owpoll" that would be configured to
poll owserver.
1. The overhead of communicating with owserver is negligible. (just
chain some owservers together to prove this).
2. owpoll could implement it's own configuration and communication
system. It's not clear how you'd want the signalling to be done.
3. owpoll could also act as a passthough to owserver to simplify the
client connections.
4. Perhaps owpoll could have some intelligence about what frequency to
poll given items.
)
On the other hand, 1-wire has a assynchronous presence detect mote for
some bus masters that we don't exploit. Because it's hard to do for
serial connections, and any communication on the bus can interfere
with it. I suppose that we could use it on the USB bus. owlib knows
when the bus is idle and so could sense new connections during that
period. (This only works for ibuttons being plugged in, not new sensor
values, those still need polling.)
------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
