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

[James C. <ca...@vi...>]

>I thought that JAPL was going to be a separate specification, since it 
>would/might have applicability outside of an Embedlet container?

With my recommendation, the APT PeripheralFactory upon which everything
sits is provided by the Embedlet Container implementation but it can
also be provided elsewhere - for example the UVMRunnable provides it
already. Which means the JAPL library can be used outside of the
Embedlet container also.


James Caska
www.muvium.com
uVM - 'Java Bred for Embedded'



-----Original Message-----
From: emb...@li...
[mailto:emb...@li...] On Behalf Of
Andrzej Jan Taramina
Sent: Monday, 31 March 2003 1:07 AM
To: emb...@li...
Subject: [Embedlets-dev] Re: JAPL part of specification


Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
_______________________________________________

Brill asks:

I thought that JAPL was going to be a separate specification, since it 
would/might have applicability outside of an Embedlet container?

> So... what I need to understand is how Outpost would be setting and 
> getting attributes of a peripheral?

An Embedlet would have a reference to the JAPL device and would use
whatever 
API the JAPL device exposed to set/get any attributes the device had
exposed.

> > Can you give a bit more information about the idea behind these Type

> > IDs?

Embedlet Event Types are just a string, which is tokens separated by
periods. 
Something like my.event.id.  or device.id.eventtype.  The first token
should 
not be emb or outpost, and don't use *'s in the type (those are used for

pattern matching), other than that, no real restrictions.

> I started Piccadilly (what I'm calling the Outpost/JAPL combo) by 
> extending Embedlet... the methods are fairly easy to understand.

You should not need to (and I feel shouldn't anyway) extend Embedlet to 
support JAPL devices.  See below.

> What I don't understand is how the embeled talks to the JAPL device. 
> What is looked like, extending Embedlet is that the embedlet receives 
> events from the system... now I assumed that I would do something 
> different depending on the event code.

Assuming that the JAPL stuff is intended to be independent of the
Embedlet 
container (something we talked about a long time ago), here is the way I

think you should consider linking the two:

1) Create your JAPL drivers with an exposed API.  The JAPL device should
NOT 
have a reference to any Embedlets, nor be dependent on ANYTHING in the 
embedlet spec (eg. no imports of org.embedlet or org.outpost packages).

2) Create an Embedlet (application logic that wishes to use a JAPL
device) 
that receives Embedlet Events that will originate from a JAPL device
somehow. 
The Embedlet can have a reference to the JAPL device if it needs it (or
it 
can be passed in as part of the Embedlet Event it receives) so that it
can 
make calls against the exposed API of the JAPL device.

3) Create a "proxy" wrapper for the JAPL driver that extends 
org.embedlet.EventProducer and which takes JAPL events (interrupts) and
then 
creates/sends an appropriate Embedlet Event.  Note that this wrapper
does NOT 
extend Embedlet (it doesn't have to), just EventProducer and that the
JAPL 
driver can have a reference to the wrapper (if needed) for interrupt
driver 
events (in which case the wrapper should implement a callback interface 
defined as part of the JAPL device API for such callbacks). The JAPL
wrapper 
should NOT have a reference to any Embedlets.  All this wrapper does is 
convert internal JAPL information into an Embedlet Event, acting as a 
"bridge" between the two worlds.

A polling scenario doesn't need the wrapper (an Embedlet would use the
Timer 
Service to poll the JAPL device), so let's look at an interrupt driven
JAPL 
device.  Here is what the flow would look like:

1) JAPL device gets an interrupt.
2) JAPL device does a callback into the JAPL "Proxy" Wrapper.
3) The wrapper takes the interrupt data, puts in in an Embedlet Event
and 
sends it (note: it does not know who the consumers are going to be).
4) An Embedlet (registered as a consumer for that particular event type)

receives the event and then does something with it (possibly issuing
JAPL API 
calls against the originating device, setting/getting attributes).

This approach follows best practices (per my earlier email), and is
preferred 
for the following reasons:

1) Coupling between the Embedlet and JAPL layers is reduced (and kept
uni- directional, from Embedlet to JAPL only).

2) The use of a wrapper class means JAPL code can be used without change

outside of the Embedlet Container environment (a good thing).

Make sense?  Do I need to write an example to show you how this is
intended 
to be implemented?

Anyone else out there?  Gregg?  Chris?  You guys got any opinions?

Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com



-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
_______________________________________________
Embedlets-developer mailing list
Emb...@li...
https://lists.sourceforge.net/lists/listinfo/embedlets-developer