[Embedlets-dev] Re: JAPL part of specification

[Andrzej J. T. <an...@ch...>]

Brill says:

> 'm thinking that they shouldn't have *any* relationship besides one being able
> to talk to the other. The idea being the separation of the two different APIs
> and their respective domains...

Exactly my thinking.  Which leads to the need for a "mediation" layer, like 
the JAPL Wrapper class that I have proposed as a "best practice" programming 
paradigm when using both Embedlets and JAPL together.  It allows for clean 
separation of the two layers.

> what I intuitively expect, is that I can instantiate a peripheral in an
> embedlet, similar to the way I might for a servlet and use that interface to
> get/set attributes of the peripheral, including finding out what JAPL
> interface it is talking to/with (Port, Temperature etc).

Yup.....Embedlets would instantiate the JAPL stuff in their initialize() or 
start() lifecycle methods and keep a reference to the JAPL peripheral (if 
they needed to) so they could get/set attributes of the peripheral as needed. 
However, the JAPL peripheral would not know anything about Embedlets or even 
if it is running in a Container or not.  Maximum reuse of JAPL code that way.

> You should be also to ask the Outpost container "what to you have" and it
> should be able to tell you (this is outpost implementation, not embedlet or
> JAPL)... 

It does that already.  You can get some Container level info in the current 
Outpost API (version, etc.).

> you could then ask each embedlet what type of interface it was
> controlling... however this would be implementation specific to something like
> the wiring tool. Anyway, the embedlet would tell your wiring tool that it
> controlled a Port... wiring already knows what a port is because you have the
> API already on your system, or the properties are coded etc. 

It would be based on the XML Config files and maybe properties at runtime.  I 
don't want to put much if any dynamic config information into the runtime 
system since that will be a strain on less capable platforms.  Many Embedlet 
containers will be "pre-compiled" with their components to fit on smaller 
platforms like TINI or uVM.  Don't count on having a runtime dynamic 
interface for wiring.  Not a big deal since the wiring tool is a "build time" 
activity and would have access to the config information (out of the XML 
files) in other ways.

> Also, the
> Port peripheral might be able to generate events or interrupts (not on the
> TINI unfortunately, but on other chips maybe) so you might tell the Port to
> report any changes... it would create its own peripheral event listener, and
> if it thought it should sent the embedlet event, it would then generate it
> (i.e. as in temperature moving outside an alarm window, the peripheral would
> get an event, but doesn't *have* to send it out to outpost)... It could also
> report changes made by other application, so two remote clients get change
> events from outpost when one or the other makes a change (with the added
> benefit of confirming a change, if its allowed to report and event like that
> back to the caller).

Exactly my thinking on what the JAPL Wrapper class should do!

> IMO - this is the *only* way to do it if you want to maintain the separation
> (though I'm open to alternative ideas). Of course, you could also integrate
> the JAPL into the embedlet api, but then you loose the JAPL and it *becomes*
> the embedlet api... and I'm not willing to do that, although your welcome to
> the code ;) 

I agree.  They need to be kept decoupled.

> my JAPL to Outpost implementation is "Piccadilly" (some of you
> might understand the reference) and that is what I'm trying to do with it.

I'm feeling dense....what is the reference to?

> I think I'm just missing how the IO in the embedlet world is done... I
> haven't had a lot of time lately, but am still plugging away....

IO to peripherals would be through the JAPL API's (and using JAPL Wrappers 
where needed for async/interrupt driven stuff).  Other IO would be done 
through Container Services (events, logging, persistence, etc.) or through 
appropriate Adapters that link to the outside world.

Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com