[Embedlets-dev] Re: [arch] JAPL Events

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

Andrzej,

>How are the JAPL events triggered?  Interrupt?  Polled?

In the case of RoboCode, the model is definitely interrupt driven.  In addition
to this, the RoboCode event objects contain rich semantics that need to be
dealt with.  For example, the robocode.ScannedRobotEvent contains these
methods:

    double getBearing()
    double getBearingRadians()
    double getDistance()
    double getEnergy()
    double getHeading()
    double getHeadingRadians()
    double getLife()
    String getName()



>If Interrupt driven, one way would be to write a Robot JAPL 
>driver routine  that implements the EventProducer interface, 
>and have the Robot JAPL driver get/store a reference to the 
>Event Service (there is a static method you can use in Container 
>to get the EventService instance).  The driver would then post 
>a suitable Robot Embedlet event (using the EventService to 
>send() the event) when the interrupt triggers.  Downstream 
>devices/components should not know what upstream components 
>are "listening" for their events typically, since that produces 
>too much coupling.

Before I posted my initial question I thought about this one a great deal and
what I came up with is that this would require another type of software entity
to be added to the Embedlet framework besides a Adapters, Transports and
Embedlet.  Before going this route I thought that we should discuss it and
probably at least try to solve the problem another way.  

Apart from this, it appears that the JAPL peripherals are well suited to use
method calls for commands being sent to them and simple callbacks for any
interrupts/events that they might generate.



>I would advise against having the JAPL device issue a callback 
>against an Embedlet instance.....since that again couples the 
>two layers a bit too closely.  The Event Service is the preferred 
>way to interface two layers together (per the above suggestions).
>Send an Event, Ted! ;-)

I am all for going with whatever makes sense here and my thinking so far on
this topic is as follows.  The Architecture document already shows Embedlets
having direct references to JAPL objects and so far my RoboCode experiments
confirm that this is a good idea.  If an Embedlet has a reference to a JAPL
peripheral then it is already closely coupled with it and in my opinion this is
not a problem because the JAPL's abstract nature already provides the required
level of decoupling.  

The only thing we are missing now is a way for a JAPL peripheral to send
asynchronous information back to the Embedlet that has a reference to it and
using a simple callback for this purpose seems to solve this problem
adequately.  If there is then a need to propagate this information to the reset
of the components in the Embedlet container then the Embedlet that contains the
JAPL peripheral can then translate the JAPL event it received into an Embedlet
event and send it to the container.

It is starting to look like there are going to eventually be thousands of JAPL
peripherals and it is going to be normal for developers to create them
'on-the-fly' just like I am doing with the RoboCode I/O systems.  Since most of
a developer's effort will probably be focused on the Embedlets anyway it also
seems like it might be a good idea to have the JAPL related development be
confined to the Embedlets too.

If this line of thinking is followed to its logical conclusion then JAPL
peripherals are completely encapsulated inside of Embedlets and showing them
attached to the periphery of the Embedlet container is not an accurate
depiction.

I suppose that the 'Embedlets having direct references to JAPL peripherals'
model that is shown in the Architecture document is either a good idea or it is
not a good idea.  If it is a good idea then I do not see a problem with
completing the connection by allowing the JAPL peripheral to send callbacks to
the Embedlet that contains it.  If it is not a good idea then this implies that
Embedlets should not contain direct references to JAPL peripherals at all and
then we will need to come up with another way to solve this problem.

At this point I would vote for exploring the callback model and see how it
plays.



>ComponentContext objects are passive data holders ONLY!  They 
>should never be registered as a callback object, since that would 
>imply that they would have to have application logic in them.

Well, am I correct in assuming that the container only instantiates one
conventional instance of each Embedlet and that the ComponentContext objects
are then used to hold the state of multiple Embedlets?  If so, then is it
reasonable to have the one conventional Embedlet instance hold references to
JAPL peripherals (in instance variables) and also register itself for any
callbacks?

I am looking forward to hearing yours and others thoughts on this issue.

Ted

__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com