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

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

I'm still neck deep here... and I havn't touched the Cork/JAPL or the
Piccadilly embedlets container since I started...
If anyone on the list would like to manage the current Cork/JAPL tree, and
maybe work out some of the remaining issues, I'd be glad to hand it off for
a while.

I will have to dive back in eventually, but I have had *no* time recently.

- Brill Pappin


----- Original Message ----- 
From: "Ted Kosan" <tk...@ya...>
To: <emb...@li...>
Sent: Thursday, May 29, 2003 6:54 PM
Subject: [Embedlets-dev] RE: repost of JAPL question...


> Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
> _______________________________________________
>
> 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
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: eBay
> Get office equipment for less on eBay!
> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> _______________________________________________
> Embedlets-developer mailing list
> Emb...@li...
> https://lists.sourceforge.net/lists/listinfo/embedlets-developer
>