[Embedlets-dev] Device polling

[Brill P. <bri...@ro...>]

Re: Outpost_ArchitectureDiscussionDocument_13.pdf
Page: 12 (bottom)

I'm a little concerned about allowing "device polling and timing" to be
entirely in the domain of the embedlet service(s), if in its domain at all.

I think it would be better if the embedlet service(s) *requested* specific
polling "properties" from the JAPL, however polling is something that can be
device and processor dependant (sometimes in the extreme).

A processor or JAPL implementation should be allowed to define it's own
polling rates etc... for instance, most temperature sensors require quite a
bit of time to show any significant changes... the JAPL implementation will
know how fast a device responds, and can tailor itself accordingly.

I think what might be a slightly better approach (though I have not entirely
thought it through) is if the embedlet service(s) could tell a JAPL impl. to
notify it through an event when a change occurred... so for instance in the
Temperature sensor example, the embedlet container would be able to give the
sensor a change window, and receive an event when the actual JAPL
implementation determined that it was warranted.

In the case where the state of the peripheral was requested from the remote
system, it would be a fairly simple task for the outpost module to store the
last state and return that. Some devices of course should not be event
driven, but most I can think of off the top of my head would best be
implemented that way.

What this means, is that the embedlet service(s) have no control over the
polling or timing rates etc... which is the opposite of the current spec.
discussion (and why I bring it up).

Thoughts?

- Brill Pappin
  Rogue Robotics
  www.roguerobotics.com