[Embedlets-dev] Re: JAPL Events

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

James misunderstands:

> Yes, but the catch 22 of this is that if you make JAPL dependent on
> embedlets then the enourmous effort required to build the JAPL library,
> which is actually an absolutely massive library, dependent on the
> embedlet event scheme.

I am not proposing that JAPL be dependent on Embedlets.  That would be a terrible idea!  I 
thought I was clear on that.

JAPL should be JAPL....and Embedlets are Embedlets.  The two should be totally 
independent of each other (meaning no dependencies in the core libraries).

However, we all agree that Embedlets (specific applications) need to interact with JAPL 
peripherals.  My proposal is that to bridge the two worlds the Application developers (like 
Ted with his Robocode stuff, or UART use for a specific application), create a proxy class. 
This is an application-specific class....not part of the JAPL spec nor the Embedlet container.  
It would proxy JAPL callbacks/interrupts and "convert" them into Embedlet events for 
upstream consumption.  I suppose I shouldn't have called the class JAPLWrapper. It would 
be more like RobocodeWrapper or UARTGPSDataWrapper or MotorCutoffSwitchWrapper.

> I think it makes sense for embedlets to talk to
> other embedlets in an embedlets container but why constrain everything
> else to use the embedlets framework? No JAPL has a very valuable life of
> its' own independent of the embedlets container actually so I don't
> agree that JAPL drivers mandatorially use the embedlet container event
> handler.

Exactly my point as well.  Similarily Embedlets should not have to deal with the JAPL world 
of interrupts/callbacks either.  Which leads inescapably to the use of a proxy class that sits 
between the two and mediates the communication between the two worlds.  But these 
"mediation" classes are app specific and so should be coded by the application developers 
NOT the Embedlet Container nor JAPL library teams.

Brill then added:

> Yes, but the API's don't have to intermingle here... it would be fairly easy to
> create an embedlet event proxy that implemented the JAPL EventListener and/or
> EventGenerator... so it's really implementation dependant, and not part of ether
> API.

Yup....but the point is that the "proxy" should not be an Embedlet (eg extend 
org.embedlet.Embedlet).  It would implement select interfaces from both sides of the fence: 
JAPLEventListener so that it can receive JAPL interrupts/events, and 
org.embedlet.EventProducer so that it can then send those interrupts upstream as 
Embedlet events.

Using a distinct class that is neither a JAPL Peripheral nor an Embedlet (component) to 
mediate between the two layers is a very clean way to bridge the two worlds.

...Andrzej

Chaeron Corporation
http://www.chaeron.com