[Embedlets-dev] RE: repost of JAPL question...

[Ted K. <tk...@ya...>]

I am in the process of jumping back into Embedlets 'hot-and-heavy' again
(details to follow) but I would like to work through the JAPL Wrapper issue
first.  The following is a repost of my latest question on this issue and I
still really want to be convinced that using a JAPL Wrapper to only receive
messages from a JAPL device and using an Embedlet to only send messages to a
JAPL device is a good idea.

Ted


</repost>

Andrzej,

>Have my explanations of the use of a JAPL Wrapper class helped resolve this?

Well, we are getting there but I still have some more questions so I hope you
will bear with me!  ;-)



>Maybe I am misinterpreting what JAPL does. If all it provides is a 
>thin generalization layer for specific classes of peripherals, then 
>we may need a Device Driver level of code layered on top of that.

The understanding of JAPL peripherals that I have been working under is that
they are generic, standardized interfaces for any kind of peripheral I/O
circuits from simple I/O ports through medium complexity devices like UARTs and
up to highly sophisticated I/O systems like a RobotScanner.  My working
definition of what a device driver means in the context of Embedlets is that it
is the piece of software that is responsible for doing the impedance matching
between the I/O level semantics of the JAPL peripheral and the application
level semantics of the Embedlet based application.

For example, if a cannon were attached to bit 3 of a JAPL I/O port, then an
event like “fire forward cannon” from the FireControl Embedlet would eventually
get translated into something like JaplPort.setBit(3, true);


>As for the asynchronous notifications (interrupts basically), see my 
>last post about using a JAPL Wrapper class as a mediation layer that 
>converts such an async callback into an Embedlet Event.  There is 
>MASSIVE benefit to using such an approach....the principal one being 
>keeping the JAPL and Embedlet layers nicely decoupled and flexible 
>(so that JAPL can be used outside of an Embedlet Container).

Well, I am trying to understand how the Embedlet registering itself as a
listener for Events coming from a JAPL peripheral it already has a reference to
makes the JAPL peripheral at all dependent on the Embedlet code base?  My
approach was to have the JAPL library contain an interface like the following:

package org.japl;

public interface JaplEventListener
{
    void receiveJaplEvent(Object japlEvent);
}//end method

and then the Embedlet would implement this interface and then register itself
as a JaplEventListener just like any other JAPL client would.  If the Embedlet
already has a dependency on the JAPL peripheral, what is the harm of allowing
it to have a further dependency on a JAPL interface?

My thought was that for any given JAPL peripheral, one Embedlet in the
application would be used to wrap around it and then all the code needed to
perform the semantic impedance matching with this JAPL device would be isolated
inside of this single Embedlet (including messaging code and JAPL event
handling code).


>1) Hold direct references to JAPL peripherals.
>2) Accept interrupt events from these peripherals.
>3) Convert the peripheral's interrupt events into Embedlet events.
>
>The combination of the JAPL peripheral (and any "device driver code) 
>and the proposed JAPL wrapper approach nicely handle all of the 
>above situations. But an Embedlet can hold a reference to a JAPL 
>peripheral (so as to issue API method calls on it to get it's work 
>done.  eg.  japl.setSwitch( true ) ).

I am still trying to understand what the benefit is of allowing an Embedlet to
send sub-application-semantic-level messages directly to a JAPL peripheral but
to have sub-application-semantic-level  asynchronous events coming from the
JAPL peripheral to be broadcast to an arbitrary number of Embedlets via the
Embedlets event mechanism?

I think you are going to say that the JAPL wrapper will convert between the I/O
level semantics of the JAPL peripheral and the application-level semantics of
the application but I still can't see why all of this impedance matching is not
happening in one place (either all in one Embedlet or all in the JAPL wrapper)?

From my perspective, this is the kind of situation that is confusing me:

- A SerialTerminalEmbedlet instantiates a JaplUart peripheral and initializes
it to 9600,8,N,1 in its initialize() method using I/O level semantics.

- All application-semantic-level data that is sent to the terminal's screen by
other Embedlets in the application is sent via Embedlet events to the
SerialTerminalEmbedlet because it is the only piece of software in the
application that has a reference to the JaplUart and so can send messages to
it.


- As asynchronous I/O level semantic data comes in from the JaplUart, it is
routed through the JAPL wrapper and then published to the Embedlet event
system.  As posted in earlier emails, only application level semantics should
be sent through the Embedlet event system so the JAPL wrapper would need to
convert the I/O event semantics into application level semantics before
publishing to the application.

So, why does all of the outgoing Embedlet/JAPL impedance matching happen in an
Embedlet and all of the incoming JAPL/Embedlet impedance matching happen in a
completely separate and unrelated piece of software (the JAPL wrapper)?  Why
not let one Embedlet handle impedance matching in both directions since having
an Embedlet implement something like the JaplEventListener interface completely
prevents JAPL peripherals from having dependencies on Embedlets?


Again, my main goal here is to completely understand the reasoning behind the
decisions being made in this part of the architecture so please bear with me
because I am having a tough time with it!  ;-)

Ted

</repost>

__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com