[Embedlets-dev] Device polling
Status: Alpha
Brought to you by:
tkosan
|
From: Brill P. <bri...@ro...> - 2003-02-14 07:20:27
|
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 |