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

[Christopher S. <cs...@oo...>]

This make the most sense to me as well.

I like the one-way-awareness approach where JAPL does not care what is
utilizing it and the JAPL layer is buffered by the JAPLEventProducer to
limit the upstream entanglement.

Chris

> 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
>