Re: [Embedlets-dev] Re: JAPL part of specification

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

> >For instance... for a starter, I was working on the tini 8 bit port... a
> >nice easy one to do... Anyway, I can set it to anything I like, but its
> >meaningless unless connected to the outside somewhere.
> >
> >So... what I need to understand is how Outpost would be setting and
getting
> >attributes of a peripheral?
>
> It does appear that JAPL and its relationship with Embedlets needs to be
> discussed more.  I am sure that Andrzej will have some more thoughts on
this
> subject and I would also like to hear what Chris, Gregg and James have to
say
> about it too.

I'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...

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).

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)... 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. You would
then make an embedlet request asking the port to set it's state to "n".
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).

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 ;) 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 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....

- Brill Pappin