Thread: [Embedlets-dev] RE: repost of JAPL question...
Status: Alpha
Brought to you by:
tkosan
Menu
▾
▴
embedlets-developer
|
From: Ted K. <tk...@ya...> - 2003-05-29 22:54:01
|
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
|
|
From: James C. <ca...@vi...> - 2003-05-30 02:17:49
|
Hi All, Well I am coming out of hibernation also! Having just cleared a contract.. so I am cashed up and ready to burn some muvium and embedlet hours 24x7 for at least the next 6 months so get ready for the final onslaught. I want to jump back into this JAPL conversation because I have the whole time held a slightly different opinion to the breakup of the JAPL layer and I think it is important for my goals with muvium to converge nicely on the Embedlet layers. Now that I have completed the port to the 18F family ( you heard it here first ) you get up to 64k program space on the 18F8720 and when you think about what squeezes on the 8K uvm-877A that's A LOT of code - more than enough to host a serious embedlet container.. Especially when I throw in extended mode with a 32K external RAM for heap.. So muvium is certainly going to be embedlet capable.. Also of note will be the embedlet container running in Virtual Breadboard/ muvium emulation.. Which means virtual circuits (with nice graphics for Ted) with all sorts of moving robots and stepper motors all controlled from an embedlet container emulation. Excellent way for people to learn about/develop for/contribute to the embedlets codebase without having to even touch a real chip or wire a real robot or blow anything up! I think this is a very important step.. The convergence of Virtual Breadboard with muvium real-time emulation, and any Embedlet containers compliant JVM's, .. May even make a special type of breadboard that you can drop wireable components to create applications.. Lot's of scope. The implementation of the embedlet container itself for muvium is something I will implement in assembler so it needs to be pretty clear what I am building before I build it as assemblers a bitch so that's why they invented java :-) Well, just a heads up really. I am moving (again) this weekend to (another) new homebase in Holland this time so once I am settled in it will be full stream ahead! (pun intended) Cheers all, James Caska www.muvium.com uVM - 'Java Bred for Embedded' -----Original Message----- From: emb...@li... [mailto:emb...@li...] On Behalf Of Ted Kosan Sent: Thursday, 29 May 2003 11:54 PM To: emb...@li... 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 |
|
From: Brill P. <bri...@ro...> - 2003-05-30 04:34:47
|
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
>
|
|
From: Ted K. <tk...@ya...> - 2003-06-02 03:17:32
|
Brill, > 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. It is kind of tough to move forward until we get the JAPL concept nailed down a bit more so it seems best to have Cork/JAPL remain in a holding pattern for a while longer. > I will have to dive back in eventually, but I have had *no* time recently. Hopefully this means that business has been good? Ted __________________________________ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com |
|
From: Christopher S. <cs...@oo...> - 2003-05-30 07:01:32
|
To clarify (I hope)
It is usually advisable to maintain unidirectional visibility from the top
of a functional stack toward the bottom. This allows lower levels to be
utilized in a variety of unforeseen but useful ways, without dependence on
superfluous functionality of the upper layers.
My feeling is that it is Ok for Embedlets to be aware of and utilize the
JAPL Abstract API only, not the concrete JAPL classes. JAPL should not be
aware of the Embedlet layer (with one caviate). Here is the logic:
1. JAPL is in place to buffer the application logic (Embedlets) from the
nasty details of hardware initialization, operation and vendor specifics.
All that JAPL needs to know for that task is the hardware details, some way
to receive initialization properties and send notifications back.
2. Asynchronous communication back to the application logic should be
handled by a JAPLEvent notifying a JAPLEventListener. Embedlets can receive
events in this manner and translate them into the appropriate EmbedletEvent.
(this is already agreed to by all, I believe )
4. The JAPL layer should be isolated from Embedlets via interfaces so that
the implementing JAPL classes can be readily swapped out to accommodate
different hardware platforms. Embedlets should NEVER reference or
instantiate a concrete JAPL class.
5. JAPL should provide for dynamic instantiation of the implementing classes
in order to disconnect the Embedlet from specific JAPL classes and
properties. This neatly skirts the issue of where the 'impedance match'
takes place as you will see below. Each class handles it's specific
responsibility.
6. The JAPL API should be devoid of hardware specific references like
setBaudRate(9600), setParity(1), getPinNumber(0x80), setRegister(0x10,0xf4)
etc. These should be handled in the JAPL initialization code under the
covers. Embedlets should be able to simply 'grab' an output and start
sending info.
Here is a short code segment that outlines my expectation of an
Embedlet/JAPLOutput interaction, The input scenario would be a mirror image.
/** An vendor neutral Embedlet to adapt a Vendor specific JAPL output
driver.
* Provides an initialization environment and Event translation for the
driver.
*/
public class BooleanOutput extends Embedlet implements EventComsumer,
Persistent{
private JAPLBooleanOutput output; // Interface only - no reference to
concrete JAPL class
private EventProducer eventSource;
private boolean value;
//...
/** Component property initialization from Persistent interface
*/
public void readProperties(Properties properties) {
value = properties.getIntProperty("InitialValue", value);
// The specific JAPL class and its properties are defined
// in the persistent initialization store. The Embedlet is just grabing
// a reference to a ready-to-go JAPL device
output = properties.getObjectProperty("OutputDevice", output);
// Embedlet wiring
eventSource = properties.getObjectProperty("EventSource", eventSource);
}
/** Component initialization
*/
public void initialize() {
// Housekeeping
super.initialize();
// These may be handled by the container
// Connect the wiring
eventSource.registerEventConsumer(this);
// Notify the output to get ready
output.initialize();
}
/** Component start signal
*/
public void start() {
super.start();
output.setValue(value);
}
/** Service the incoming embedlet event by sending the boolean value
* on to the JAPLOutput
*/
public void receive(Event event) {
BooleanEvent e = event;
value = e.getValue();
output.setValue(value);
}
}
(Please excuse any none-compile-able code this is for demonstration of
principle only)
The assumption here is that JAPL class implements the Persistent interface
so that it can be dynamically instantiated and receive initialization
parameters independent of the Embedlet (I can hear the uproar already). Note
that the Embedlet does not know any of the specifics of the underlying JAPL
device, other than it takes a boolean value and makes something happen out
there.
The deployment scenario would be:
1. A vendor provides the JAPL driver class (jar) and an XML snippet to
initialize the device.
2. The class gets included in the classPath or 'forName' linker list
3. The XML snippet gets placed inside of the Embedlet deployment descriptor:
<Embedlet
name="DoorOpen"
class="org.embedlet.io.BooleanOutput"
InitialValue="true">
<!-- Vendor specific IO driver snippet-->
<Output
name="IODriver"
class="com.acme.io.GPIOPortPin"
pinNumber="0x80"
direction="1"
/>
<!-- End of vendor IO driver snippet-->
<!-- Embedlet event wiring -->
<EventSource href="components.logic.overflowLimit">
</Embedlet>
Using these guidelines there should be little overlap of functionality or
control. The layers are cleanly isolated yet interact efficiently.
The issue is going to be the dependence on the Persistent interface. My
response to that is that there is no way to avoid 'persistence' in a general
sense. Hard coded initialization of variables is a form of read-only
persistence. If the issue is not addressed at the JAPL level then it just
gets pushed up to the Embedlet level. Then every JAPL driver would need to
have a 'brother' Embedlet to manage its initialization. Pushing the
Persistent interface down to the JAPL level allows the layers to work
independent of each other and manage their own initialization
responsibilities.
If the application uses hard coded initialization values it is easy to
create a 'HardCodedProperties' class that holds the values in code. In this
scenario the container instantiates the 'HardCodedProperties' class and
hands it to the Embedlet readProperties() method. The JAPLDriver and
Embedlet work the same, unaware of the source of the Properties.
This allows a common Embedlet and JAPL code base to handle the dynamic
persistence store such as XML or fileStream as well as the the hard-coded
set-and-forget initialization.
My recomendation to side step the 'unidirectional' dictate above is to move
the Persistence API outside of, but common to, the Embedlet and JAPL API's,
limiting the baggage that needs to be hauled around for that function.
I have rambled on enough for tonight, it will probably make as much sense in
the morning as those drug induced, inspirational evenings of my youth.
Christopher Smith
OopScope, LLC.
www.oopscope.com
cs...@oo...
805-276-0598
> -----Original Message-----
> From: emb...@li...
> [mailto:emb...@li...]On Behalf Of Ted
> Kosan
> Sent: Thursday, May 29, 2003 3:54 PM
> To: emb...@li...
> 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
>
|
|
From: Ted K. <tk...@ya...> - 2003-05-31 18:38:09
|
Chris, > 2. Asynchronous communication back to the application logic should be > handled by a JAPLEvent notifying a JAPLEventListener. Embedlets can receive > events in this manner and translate them into the appropriate EmbedletEvent. > (this is already agreed to by all, I believe ) This is exactly how I envisioned JAPL-to-Embedlet interactions working because it places all of the JAPL-to-Embedlet code in one place. Andrzej's position, however, is that Embedlets should never receive callback's from JAPL devices and so this is the issue we need to work through. Since a number of us are going to be unavailable for the next week or so I suppose we will defer this discussion until later. Your thoughts on leveraging the persistence mechanism in order to initialize JAPL devices are interesting. I have not looked at it that way before and I am going to have to study this approach a bit more. Since you have a new persistence release I will try to download it this weekend and give it a spin. I will try to get back to you by later on Sunday. Ted __________________________________ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com |
|
From: Christopher S. <cs...@oo...> - 2003-06-02 18:23:00
|
At some point someone has to do the talking. There is such a thing as excessive de-coupling, to the point where nothing communicates! The Event callback pattern is a standard Java design practice so it is a completely acceptable approach that has no serious drawback. The visibility is still one-way as the JAPL code is not dependent on the Embedlet API and can be used in other applications. I agree with Andrjez that JAPL should not make Embedlet Event calls - but I do not think that you were proposing this in the first place. Christopher Smith OopScope, LLC. www.oopscope.com cs...@oo... 805-276-0598 > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > _______________________________________________ > > Chris, > > > 2. Asynchronous communication back to the application logic should be > > handled by a JAPLEvent notifying a JAPLEventListener. Embedlets > can receive > > events in this manner and translate them into the appropriate > EmbedletEvent. > > (this is already agreed to by all, I believe ) > > This is exactly how I envisioned JAPL-to-Embedlet interactions > working because > it places all of the JAPL-to-Embedlet code in one place. > Andrzej's position, > however, is that Embedlets should never receive callback's from > JAPL devices > and so this is the issue we need to work through. Since a number > of us are > going to be unavailable for the next week or so I suppose we will > defer this > discussion until later. > > Your thoughts on leveraging the persistence mechanism in order to > initialize > JAPL devices are interesting. I have not looked at it that way > before and I am > going to have to study this approach a bit more. Since you have a new > persistence release I will try to download it this weekend and > give it a spin. > I will try to get back to you by later on Sunday. > > Ted > > __________________________________ > 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 > |
Thanks for helping keep SourceForge clean.
X