Re: [Embedlets-dev] [Arch] re; Device polling

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

> I have to side with Chris on this.  Creating a JAPL interface layer that
does
> device-level protocol neutralization and provides a solid generic
interface to
> arbitrary devices is challenging enough.  Then there will be the task of
> providing JAPL interfaces for the large quantity of unique hardware
devices
> out there.  KISS principle would seem to be a wise way to go for the JAPL
> layer, just due to the size of the core task.

Oh, I don't mean to say the the JAPL has to do this.. it only need to know
the contract that will allow it to configure the system, listen for events
etc.

however, the JAPL can't do a darn thing without an implementation... which
is going to have to take a lot of this into accoutn anyway... luckily
becuase COrk is in its second generation, a lot of the infrastructure is
already in place... when I finish a ref impl of the JAPL, I'll be able to
simply hook it up to cork to provide the underlaying code... and cork was
designed in second rev to be ported to other platforms (like TINI).


> Let JAPL expose a common device interface.  But let the Embedlets
determine
> how/when that interface should be invoked. Clean....simple...decoupled.

Thats what I mean, the JAPL is *just* a contract, it says nothing about the
hardware its running on etc... it only allow the embedlets to know how to
call the underlaying drivers.

> This approach has some other key benefits.  JAPL interfaces stay simple
and
> could be used by other embedded Java solutions (for example, hardcoded
> solutions that don't use an Embedlet container).  It also allows Embedlets
to
> use non-JAPL enabled devices easily, yet still leverage common services
like
> Timer/Events as needed.  Embedlets will also be configured using XML
> syntax, so that is a logical place to put things like timing requirements
(how
> often to poll a device).  Keep in mind that Timers will also be used for
other
> purposes (eg. sending a status update to a remote enterprise system on a
> periodic basis, Management services, etc), not just for device polling.

Yup, that's understood... however the JAPL doesn't need to be so tied to
Embedlet (and I don't think it should be) that it *requires* and XML
parameter to function.
In the case of a timer, of course the embedlet system is going to do the
configuration, however it will *not* have direct control over the timer...
it must control the timer through the JAPL contract.

- Brill Pappin