embedlets-developer Mailing List for Outpost Embedlet Container (Page 15)
Status: Alpha
Brought to you by:
tkosan
Menu
▾
▴
embedlets-developer — Outpost Embedlet container developer list
You can subscribe to this list here.
| 2003 |
Jan
(135) |
Feb
(402) |
Mar
(162) |
Apr
(22) |
May
(13) |
Jun
(67) |
Jul
(59) |
Aug
(27) |
Sep
(1) |
Oct
(28) |
Nov
(81) |
Dec
(16) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(2) |
Feb
(21) |
Mar
(6) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
(13) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2006 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Christopher S. <cs...@oo...> - 2003-04-01 18:52:30
|
Great! The concept is very general and applicable to a number of areas in the project including persistence, configuration and transport. I will commit the interfaces for review. Chris > > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > _______________________________________________ > > Chris said: > > >I propose that the embedlet should not 'know' the details of the > >JAPL configuration. This is hardware and/or media specific and > >usually occurs only once in the operational life of a peripheral. > > > >The Embedlet should present a configuration 'Properties' to JAPL, > >but not necessarily know the contents of the Properties. [snip] > > I *really* like this idea. As I was playing around with my Robocode > application I almost felt embarrassed by the idea of hardwiring the JAPL > configuration inside of the code and a mechanism like you are > proposing would > definitely fix this. > > Ted > > __________________________________________________ > Do you Yahoo!? > Yahoo! Tax Center - File online, calculators, forms, and more > http://platinum.yahoo.com > > > ------------------------------------------------------- > This SF.net email is sponsored by: ValueWeb: > Dedicated Hosting for just $79/mo with 500 GB of bandwidth! > No other company gives more support or power for your dedicated server > http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ > _______________________________________________ > Embedlets-developer mailing list > Emb...@li... > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > |
|
From: Ted K. <tk...@ya...> - 2003-04-01 08:30:48
|
Chris said: >I propose that the embedlet should not 'know' the details of the >JAPL configuration. This is hardware and/or media specific and >usually occurs only once in the operational life of a peripheral. > >The Embedlet should present a configuration 'Properties' to JAPL, >but not necessarily know the contents of the Properties. [snip] I *really* like this idea. As I was playing around with my Robocode application I almost felt embarrassed by the idea of hardwiring the JAPL configuration inside of the code and a mechanism like you are proposing would definitely fix this. Ted __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://platinum.yahoo.com |
|
From: Ted K. <tk...@ya...> - 2003-04-01 08:19:27
|
Andrzej, >Also Embedlets are controlled by the Container (ref: Inversion of >Control architectural design principle). If you let the JAPL >layer do callback directly into the Embedlet you have bypassed >the Container control mechanisms which could be a "very bad thing". >The container implementation may be enforcing prioritization >through the event queues, and by bypassing this with a direct >callback you may compromise realtime deterministic response >guarantees. Also a container implementation may choose to >use a dedicated thread per Embedlet....and calling into the >Embedlet using the JAPL thread could easily cause problems. Ok, this explanation is finally hitting home with me! I think that I can gain some mental traction with this issue if we discuss it in the context of threads. >There are a number of good reasons for using the "mediatory/proxy" >class to bridge the two worlds of JAPL and Embedlets.... I like the I/O Mediator idea but now I have the following question about it: I assume it is ok to allow Embedlets to have direct references to these mediators? If so then how does the following scenario work? The IOMediator has just received a callback event from a JAPL peripheral that it has a reference to and concurrently one of the Embedlets that has a reference to the IOMediator invokes one of its methods. Have we not just moved the two-threads problem referenced above out of the Embedlet and into the IOMediator? As I look back on the experimenting that I had been doing with Robocode I had actually placed an Embedlet into the IOMediator role and had it do all of the I/O semantic level - application semantic level impedance matching within itself. It was my intent that callback events received from the JAPL device would be converted into the appropriate Embedlet Event and then submitted to the Embedlet Event system. The only thing that the JAPL's callback thread would be responsible for was doing this conversion and submission. Any data that needed to be sent to the JAPL peripheral from other Embedlets would need to be sent as Embedlet events that the Mediator Embedlet would receive and then translate into method calls on the JAPL peripheral. I was not planning on placing any application logic inside of this Mediator Embedlet at all. If I can clearly understand how the IOMediator solves the two-threads problem I think I can embrace it with no reservations. >I hope this long description and examples help. Oh yes, very much so! And when people start asking us tough questions during our JavaOne and Embedded Systems conference presentations, these explanations will definitely come in handy too! ;-) Ted __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://platinum.yahoo.com |
|
From: Andrzej J. T. <an...@ch...> - 2003-04-01 02:49:22
|
Ted sed:
> Well, we are getting there but I still have some more questions so I hop=
e
> you will bear with me! ;-)
No problem, Ted. That's what this list is for.
> The understanding of JAPL peripherals that I have been working under is
> that they are generic, standardized interfaces for any kind of periphera=
l
> I/O circuits from simple I/O ports through medium complexity devices lik=
e
> UARTs and up to highly sophisticated I/O systems like a RobotScanner.
That is how I perceive JAPL peripherals as well.
> 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.
I think of device drivers more like Windows drivers. They are typically n=
ot application specific, just
expose a higher level device API. And hence my use of the terms JAPL peri=
pheral and device
driver synonymously.
> For example, if a cannon were attached to bit 3 of a JAPL I/O port, then
> an event like =93fire forward cannon=94 from the FireControl Embedlet wo=
uld
> eventually get translated into something like JaplPort.setBit(3, true);
I would call JaplPort.setBit(3, true); the device driver level. The fireF=
orwardCannon() method,
implemented in a more application specific class is something I would put =
in a wrapper above
JAPL but below Embedlets.
> Well, I am trying to understand how the Embedlet implementing a JAPL
> interface and registering itself as a listener for Events coming from a
> JAPL peripheral (that it already has a reference to) using this interfac=
e
> makes the JAPL peripheral at all dependent on the Embedlet code base?
It doesn't. It makes the Embedlet application code too dependent on JAPL =
code, and more
specifically, dependent on JAPL interrupts/events. Reasons why this is a =
"bad thing" later in this
email.
> and then the Embedlet would implement this interface and then register
> itself as a JaplEventListener just like any other JAPL client would.
You're close.....I am suggesting that the best practices approach is to us=
e three distinct classes:
1) JAPL Peripheral (possibly with a more app-specific layer over the top t=
o provide things like the
fireForwardCannon() method).
2) A FireControl Embedlet that responds to EnemyInRange Embedlet Events (a=
nd which would
possibly call the fireForwardCannon() method if it determined that it shou=
ld/could fire).
3) A class that acts as a bridge between these two. Call it a wrapper/pro=
xy/translator/mediator. It
implements JAPLEventListener and org.embedlet.event.EventProducer. When i=
t gets called
with a JAPL Event (if we detected an enemy in range) all it does is create=
a new Embedlet Event,
attach any relevant info (maybe the JAPLEvent set as the UserData in the E=
mbedlet Event) and
sends the Embedlet Event.
In our example, it would look something like this:
public class EnemyDetectorMediator implements JAPLEventListener,
org.embedlets.event.EventProducer
{
public EnemyDetectorMediator() // constructor
{
EnemyRadar radar =3D getRadarJAPLPeripheral(...);
radar.registerJAPLEventListener( this );
}
public void receiveJAPLEvent( JAPLEvent japlEvent )
{
EventService eventService =3D Container.getEventService();
EmbedletEvent event =3D eventService.getEventInstance( "enemy.detected",=
...);
event.setUserData( japlEvent.getRangeAndDirection() );
eventService.send( event );
}
}
This code is very simple. Easy to understand. Not much code required. A=
nd it isolates the
"bridging" code away from both the JAPL device stuff and the Embedlet appl=
ication code (fire
control details).
> the Embedlet already has a dependency on the JAPL peripheral, what is th=
e
> harm of allowing it to have a further dependency on a JAPL interface
> (again, there are no Embedlet dependencies in the JAPL code)?
There are a number of good reasons for using the "mediatory/proxy" class t=
o bridge the two
worlds of JAPL and Embedlets....
First, it keeps the two event models distinct and decoupled, which is a go=
od thing. This means
that your Embedlet code (FireControl) is not dependent on a particular JAP=
L implementation or
even specific devices (so you could switch between Radar ranging and Satel=
lite imagery/GPS
detection of enemies with no change to your FireControl Embedlet).
Also Embedlets are controlled by the Container (ref: Inversion of Control =
architectural design
principle). If you let the JAPL layer do a callback directly into the Emb=
edlet you have bypassed
the Container control mechanisms which could be a "very bad thing". The c=
ontainer
implementation may be enforcing prioritization through the event queues, a=
nd by bypassing this
with a direct callback you may compromise realtime deterministic response =
guarantees. Also a
container implementation may choose to use a dedicated thread per Embedlet=
....and calling into
the Embedlet using the JAPL thread could easily cause problems.
These are just two examples of why the middle "proxy" class that is NOT an=
Embedlet is a good
idea, since it avoids all of these potential issues with various container=
implementations (and
there will be many varied Embedlet container implementations that could ea=
sily make such
implementation decisions...if we are successful!).
> 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 peripheral wou=
ld
> be isolated inside of this single Embedlet (including messaging code and
> JAPL event handling code).
Close....but for the reasons above, it's better practice to use
a "mediation" class as per my example above.
> 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?
OK...let's follow on with the battle example. If you use the "mediator cl=
ass" approach, when you
first write your battlebot code, you might implement just the FireControl =
Embedlet. This is a
simple case so you are right to question why go to the bother of creating=
the separate
"mediation" class since only one Embedlet will receive the events.
However, as your battlebot evolves, you decide that you want to add an ana=
lysis and potential
avoidance behaviour (run way from the enemy) code, but it should be lower =
priority than firing the
cannon (since you have decided to always fire the cannon immediately upon =
sighting an enemy
as part of your battle strategy).
So you write an Avoidance Embedlet and register it to receive the EnemyDet=
ected embedlet
event. Note...you didn't change a line of code in your FireControl Embedl=
et. Nor did you change
a line of code in your JAPL classes nor in your "mediator" class that tran=
slates from the JAPL
event to the Embedlet Event. And you can tell the container to first send=
the event (using XML
config stuff) to the FireControl Embedlet, then you can analyze the situat=
ion and decide whether
to flee or not in the Avoidance Embedlet.
Look at the modularity and flexibility that you have available at your fin=
gertips, Ted! You added
advanced enemy avoidance strategy without touching a line of your other co=
de. Contrast this
with what you would have had to do if you had made the FireControl embedle=
t receive the JAPL
callback directly....you would have had to refactor a lot of code (and wou=
ld have ended up with a
mediator class anyway) or you would have mixed FireControl with Avoidance =
code, which is not a
good way to split up application requirements that are basically independe=
nt of each other.
Now you could say you could implement the "translation" of JAPL interrupts=
to Embedlet Events
with a 3rd Embedlet. But there are issues with that and the Container inv=
ersion of control
principle that I have already explained earlier.
> 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)?
See above. The impedence matching has one foot in either camp....and so i=
t makes sense to
keep it separate and in the middle, rather than try to arbitrarily force i=
t to live on either side of the
fence.
It has the nice side benefit of separating the "bridging" code away from t=
he device and/or
application code. This makes the final app easier to maintain, and easier=
to understand, since
you are not mixing roles/functions.
> From my perspective, this is the kind of situation that is confusing me:
Do the above descriptions help lessen the confusion at all?
> 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 JAP=
L
> wrapper)?
I should not have called the piece of code that bridges the two worlds the=
JAPL Wrapper,. Since
it's not part of JAPL...nor is it part of Embedlets....it sits on the fenc=
e and acts as "glue" between
the two. that might be confusing you. And you only need to fix the impe=
dence mismatch
problem between the two event models (see many reasons as to why above) wh=
en the JAPL
device is using an interrupt driven approach.
If you are just issuing a method call against the JAPL layer from the Embe=
dlet, that does not
compromise the Container Inversion of Control principles, and is akin to c=
alling a lower level
method to do your work. So that is OK.
> 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?
See above for reasons why. The only point I'm trying to make is that the =
"thing" that handles the
impedence mismatch should not be a JAPL nor an Embedlet. It's a thing unt=
o itself...with one
foot in each camp per my example.
In fact, you could create a class that handled the translation between the=
two event models AND
also provided application level semantics to the Embedlets (eg. add a setD=
etectorSensitivity()
method to the example EnemyDetectorMediator class I outlined above).
> Again, my main goal here is to completely understand the reasoning behin=
d
> the decisions being made in this part of the architecture so please bear
> with me because I am having a tough time with it! ;-)
I hope this long description and examples help. You're pretty close to ge=
tting it! ;-)
...Andrzej
Chaeron Corporation
http://www.chaeron.com
|
|
From: Andrzej J. T. <an...@ch...> - 2003-04-01 02:49:18
|
Chris comes clean: > I had to dive into a contract just as you did. I was having so much fun on > Embedlets that I neglected some of the more trivial aspects of life such as > feeding the kids. > > I will commit a portion of my day to Embedlets from this point forward. Um, Chris....don't starve the kids on our account! <grins> ...Andrzej Chaeron Corporation http://www.chaeron.com |
|
From: Christopher S. <cs...@oo...> - 2003-04-01 00:53:16
|
____________________________________________ > > Chris says (welcome back Chris!): > > > I think that Andrzej has addressed this: > > > > Embedlets need to know about JAPL not the other way around. > > That I agree with wholeheartedly. > > > Embedlets (or the JAPLEventProducer) register as JAPLEventListeners to > > receive async notification > > Not quite. I am very uncomfortable with an Embedlet registering > as a JAPLEventListener > and then having callbacks issued on the Embedlet. I can think of > certain container > implementations where this could be problematic. I suggest that > the creation of a proxy > class (JAPLWrapper) that registers as a JAPLEventListener and > then proxies the data into > the Embedlet world as an Embedlet Event is a much better solution > architecturally. > Agreed > > If we agree on the portability criteria as the functional dividing line > > there is little overlap and everyone keeps on truckin'. > > True enough. > > ...Andrzej > > Chaeron Corporation > http://www.chaeron.com > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: ValueWeb: > Dedicated Hosting for just $79/mo with 500 GB of bandwidth! > No other company gives more support or power for your dedicated server > http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ > _______________________________________________ > Embedlets-developer mailing list > Emb...@li... > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > |
|
From: Gregg G. W. <gr...@sk...> - 2003-04-01 00:46:55
|
>Much better explanation... and your right... the actual thing is just part >of the city ;) Lechester Square is much more fun! Yes, it is. If you want to 'see' all kinds of 'natives', it sure seemed to me like they were passing through Piccadilly on the way to the square! Man, this is bringing back memories of Courage, Guiness and Indian food! ----- gr...@cy... (Cyte Technologies Inc) |
|
From: Brill P. <bri...@ro...> - 2003-03-31 23:38:59
|
> And more specifically, it is called Piccadilly Circus, which means that it is > a circular path/road where several roads come together and then branch out > again. If you have never been there, you'd not think much of it. When I was > last there in 1990 and 1991 (on 4 different occasions), it was the place where > everything converged in London. The 'tube' (unground subway) stops near > there, and brings everyone from outlying areas into the city. The area is > probably comparable to the same thing as Time Square in NYC, in terms of > entertainment, food and what not. Much better explanation... and your right... the actual thing is just part of the city ;) Lechester Square is much more fun! - Brill Pappin |
|
From: Andrzej J. T. <an...@ch...> - 2003-03-31 23:19:41
|
Brill explains the Piccadilly reference: > It actually a place name for an area of London (eng.). You will find people > calling places Piccadilly in a lot of english literature,... also a lot of > families with English roots might name places Piccadilly (my onw family does > that at our cottage up on Lake Joseph, and N. Ontario). I've been there....so no surprise there (I'm a pommie by birth). > Anyway, it reffers to a > place "where things come togher" a cross-roads etc. I thought it apt because I'm > trying to bring Outpost and JAPL together ;) OK...that part I didn't know. Now it makes sense. A bit obscure...but makes sense. Sure hope your JAPL API/code is a bit more obvious that that reference. <grins> ...Andrzej Chaeron Corporation http://www.chaeron.com |
|
From: Andrzej J. T. <an...@ch...> - 2003-03-31 23:19:36
|
Chris says (welcome back Chris!): > I think that Andrzej has addressed this: > > Embedlets need to know about JAPL not the other way around. That I agree with wholeheartedly. > Embedlets (or the JAPLEventProducer) register as JAPLEventListeners to > receive async notification Not quite. I am very uncomfortable with an Embedlet registering as a JAPLEventListener and then having callbacks issued on the Embedlet. I can think of certain container implementations where this could be problematic. I suggest that the creation of a proxy class (JAPLWrapper) that registers as a JAPLEventListener and then proxies the data into the Embedlet world as an Embedlet Event is a much better solution architecturally. > If we agree on the portability criteria as the functional dividing line > there is little overlap and everyone keeps on truckin'. True enough. ...Andrzej Chaeron Corporation http://www.chaeron.com |
|
From: Andrzej J. T. <an...@ch...> - 2003-03-31 23:19:13
|
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 |
|
From: Andrzej J. T. <an...@ch...> - 2003-03-31 23:19:10
|
Brill asks: > Ok, so the IO does happen with events... Only for interrupt/asynchronous data (pushed data). > How does the external caller > request data from JAPL device? For pulled data, the Embedlet would just issue a JAPL API call like getSwitchStatus() against the JAPL API. No events needed. There is also a hybrid approach where an Embedlet Event is generated (by a wrapper class) when something "interesting" happens at the JAPL peripheral level. And upon receipt of the event, a particular Embedlet can issue a a JAPL API call like getSwitchStatus() against the JAPL API...or maybe a setSwitchState() call instead to actuate something. Does this clear things up a bit? ...Andrzej Chaeron Corporation http://www.chaeron.com |
|
From: Christopher S. <cs...@oo...> - 2003-03-31 20:54:12
|
Ted says:
> 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.
>
I propose that the embedlet should not 'know' the details of the JAPL
configuration. This is hardware and/or media specific and usually occurs
only once in the operational life of a peripheral.
The Embedlet should present a configuration 'Properties' to JAPL, but not
necessarily know the contents of the Properties. The Properties collection
is loaded by VM configuration settings as in the Ajile JVM setup or by a
coded PersistenceManager.
This would add a PropertyEnabled interface to the JAPL specification but
would have the huge benefit of breaking the coupling and knowledge
requirement between the API's. A snippet of code for configuration would
look like:
In the Embedlet PropertyEnabled interface:
public void readProperties(Properties properties) {
name = properties.getString("Name", name);
peripheral = (JAPLPeripheral) properties.getObject("Peripheral",
peripheral);
peripheral.readProperties(properties);
}
In the JAPL PropertyEnabled interface:
public void readProperties(Properties properties) {
baudRate = properties.getInt("BaudRate ", baudRate);
stopBits = properties.getInt("StopBits", stopBits);
...
}
The configuration XML would look like:
<Embedlet name="CommunicationChannel" ... >
<Peripheral baudRate="9600" stopBits="1" ... />
</Embedlets>
JAPL would need only import 2 new interfaces: PropertyEnabled and Properties
to utilize the configuration capabilities.
> - 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.
>
In the case where the configuration is removed from the equation the
interfaces become symetrical. Embedlets write/read to/from the JAPL stream
and JAPL notifies the Embedlets of events.
I am preparing an upgraded Property package for first release that includes
this dynamic configuration capability.
Chris
|
|
From: Christopher S. <cs...@oo...> - 2003-03-31 20:14:10
|
> > > > An embedlet should be able to register itself as a listener to a JAPL > > > event generator > > > > I strongly disagree. This couples JAPL and Embedlets too much and > bypasses > > the Embedlet Event scheduling and control mechanisms. Bad idea. If you > are > > doing that, then why bother with a container? Just write straight Java > code > > and be done with it. > > Not to mention cause the JAPL events to grind to a (almost) halt > waiting for > the Outpost container(s) to do what they need to do!. > I think that Andrzej has addressed this: Embedlets need to know about JAPL not the other way around. Embedlets (or the JAPLEventProducer) register as JAPLEventListeners to receive async notification If we agree on the portability criteria as the functional dividing line there is little overlap and everyone keeps on truckin'. Chris > - Brill Pappin > > > > ------------------------------------------------------- > 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 > |
|
From: Christopher S. <cs...@oo...> - 2003-03-31 20:07:06
|
> Ted says > > > It does appear that JAPL and its relationship with Embedlets needs to be > > discussed more. I am sure that Andrzej will have some more > thoughts on this > > subject > > Funny you should say that. ;-) > > > I would also like to hear what Chris, Gregg and James have to say > > about it too. > > Me too. Where are ya guys? You were hot to trot so I filled the CVS > repository and then....silence! I had to dive into a contract just as you did. I was having so much fun on Embedlets that I neglected some of the more trivial aspects of life such as feeding the kids. I will commit a portion of my day to Embedlets from this point forward. Chris > > 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 > |
|
From: Christopher S. <cs...@oo...> - 2003-03-31 20:03:07
|
________________________________________ > > >Let me repeat that: though the Embedlet can have a reference to the > JAPL > >device, the JAPL device should NOT have a reference to an Embedlet! > > An embedlet should be able to register itself as a listener to a JAPL > event generator > > That is correct, but only as a JAPLListener. This maintains the decoupling as Andrzej has pointed out. > 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: Saturday, 29 March 2003 4:56 AM > To: emb...@li... > Cc: tk...@ya... > Subject: [Embedlets-dev] Re: JAPL Events > > > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > _______________________________________________ > > Ted: > > Sorry 'bout the delay in replying. This new contract is keeping me > pretty busy and I've been too fried in the evenings to do much else. > Settling in now, so hopefully I can do some embedlet work in my spare > time. > > > 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() > > Each interrupt event should be mapped onto an Embedlet event. Note that > > using the User Data area of the Embedlet Event you can just append the > robocode event, and not have to copy any data around. > > > 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. > > Actually....it doesn't! If you think about the robocode application, > the > interrupts should be handled by a JAPL device driver, which in this case > > is a robocode "virtual" device. > > > 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. > > Exactly. And that robocode JAPL driver should convert the interrupts > into Embedlet Events before posting them so that upstream Embedlets can > do their battle planning. > > > 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. > > That is incorrect Ted! Just because an Embedlet has a reference to a > JAPL device does NOT imply that the reverse is OK. Higher order > components can have references to lower order (or more detailed, closer > to the iron) ones. However, the point of using an Event-driven model is > > to avoid the reverse, where more detailed components should not have to > know about the consumers of the events. > > This is very analagous to good programming practice where a subroutine > or > method should typically have NO knowledge of the caller. Breaking this > rule is what leads to tight coupling and inflexible application code. > > Let me repeat that: though the Embedlet can have a reference to the > JAPL > device, the JAPL device should NOT have a reference to an Embedlet! > > Let me put this another way: if I can figure out a way to prevent JAPL > devices from getting Embedlet references I will do so in the Outpost > implementation. ;-) > > The JAPL driver should be the interface to the device....in the robocode > > example, the code that handles the interrupts. If higher level > components need to know about this, then you should post an Embedlet > Event. > > The beauty of doing this using only events (not callbacks) is that later > > you can add other event consumers that add new functionality and your > JAPL code remains blissfully unaware (as it should be) that other > Embedlets are now consuming the events and performing even more complex > battle plans. > > > 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. > > NO! NO! NO!] > > Have the JAPL peripheral post an Embedlet Event. You can attach the > robocode interrupt data to the Embedlet Event...and the Producer ID > let's > you tie this back to a particular JAPL peripheral (or include a > reference > to the producing JAPL driver in the event). > > That is how components should communicate using the Embedlet standard. > Using callbacks from lower components to higher ones is against the > spirit of the Embedlet spec and is also considered a very bad > programming > practice for the reasons given. > > > 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. > > Do this in the JAPL driver. This gives you more downstream flexibility > and is the way that Embedlets were supposed to work. > > > 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. > > I'm not sure what you mean by that. > > > 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 disagree.....the whole point of the event model is to allow this > decoupling. This way you can write a single embedlet that can manage > multiple (similar) JAPL devices very easily. Longer term application > maintenance and expansion is also facilitated without needing to rewrite > > any JAPL driver code if you take my approach from day one. > > > 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. > > -1: JAPL drivers having references to Embedlets > +1: Embedlets having references to JAPL devices > -1: Using callbacks from lower order components to higher order ones > +1: Using events to pass stuff from lower order components to higher > +ones > > > 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. > > Like I said, if I can figure out a way for the Outpost implementation to > > prevent this, I will! ;-) > > > 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. > > Therein lies the fallacy of your approach, Ted. This is not a symmetric > > situation. A one way reference from Embedlet to JAPL is fine, and in > fact, was intended to be used all along. It's the reverse reference > that > is a bad idea since it breaks encapsulation and couples things too > tightly. > > A calling program can depend on a subroutine/method. But a > subroutine/method should not depend on the caller. Async relationship! > > Same with Embedlets versus JAPL drivers. > > > At this point I would vote for exploring the callback model and see > > how it plays. > > Don't do it Ted! Stay away from the dark side. Do it the "right way". > > Use event generation in your JAPL driver. > > > 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? > > Nope. Something I discussed with Chris. To allow caching of > ComponentContext data Outpost instantiates an Embedlet object for each > Embedlet that is needed (unlike servlets). But that may just be a > container implementation decision, so may not be consistent across other > > Embedlet Container implementations in the future. > > Use Events Ted....stay away from callbacks! > > ...Andrzej > > Chaeron Corporation > 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 > > > > > ------------------------------------------------------- > 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 > |
|
From: Christopher S. <cs...@oo...> - 2003-03-31 19:59:04
|
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 > |
|
From: Christopher S. <cs...@oo...> - 2003-03-31 19:52:37
|
My sugesstion here would be to define the functionality boundary between Embedlets and JAPL as those which are portable between hardware platforms and those that are not. So a UART with an IO address, Interrupt vector and setup registers should be interfaced through JAPL. Communication through the interface would be available to an Embedlet either directly or through an intervening service that provides access for multiple Embedlets. Interrupts would be translated into Embedlet events at a point that abstracts the hardware interface to a common standard for the media. In this case character(s) received not individual bits. The JAPL would have to buffer the character streams and operate on a separate thread to accomodate the difference between the synchronous nature of the hardware interface and the asychronous none deterministic nature of Embedlets. The best example of this division is the comm interface provided by Sun. You can access a comm device on a wide range of hardware devices using the same code with only minor configuration adjustments. The device/VM vendor provides the implementation that manages the underlying hardware, interrupt handling and character buffering. Using this criteria would, I feel, would reduce the discussion to a tangible baseline with little gray area. Chris > Andrzej, > > >If you think about the robocode application, the interrupts > should be handled > by a JAPL device driver, which in this case is a robocode > "virtual" device. > >[...] > And that robocode JAPL driver should convert the interrupts > into Embedlet Events before posting them so that upstream Embedlets can > do their battle planning. > > The JAPL devices are abstract peripherals, not device drivers. > Lets set aside > Robocode > for the moment and discuss a JAPL UART because I think it is more > typical of > what most JAPL devices will look like. A normal UART device > driver can a) > configure the UART by placing data into its internal registers, > b) query the > state of the UART by looking at its internal registers and c) > the UART can > asynchronously notify its device driver that it needs to be serviced by > asserting the interrupt line. > > The Architecture document gives an Embedlet 2/3 of the > capabilities it needs to > serve as a JAPL UART device driver because it allows the Embedlet > to have a > direct reference to the JAPL UART and so enables it to do 'a' and > 'b' above. > As for the UART interrupt, in all the conventional low level > device drivers I > have written, the interrupt is always channeled directly into the > device driver > that is also responsible for doing 'a' and 'b' for any given > device and it is > always a one-to-one bidirectional binding. No other piece of > code besides the > peripheral's device driver should be interested in the interrupt. > > But you are saying that Embedlets should not be used as device > drivers either > (see below). > > > > >And that robocode JAPL driver should convert the interrupts > into Embedlet Events before posting them so that upstream Embedlets can > do their battle planning. > > Again, a JAPL peripheral is just a peripheral, not a device > driver. Besides > this, the JAPL peripheral can't convert its interrupts into > Embedlet events or > any other specific system's events because the JAPL is a > generalized, system > neutral technology. > > > > >Therein lies the fallacy of your approach, Ted. This is not a symmetric > situation. A one way reference from Embedlet to JAPL is fine, and in > fact, was intended to be used all along. It's the reverse reference that > is a bad idea since it breaks encapsulation and couples things too > tightly. > > > >A calling program can depend on a subroutine/method. But a > subroutine/method should not depend on the caller. Async relationship! > Same with Embedlets versus JAPL drivers. > > If an Embedlet is being used as a device driver for a JAPL device > then I would > say that device drivers commonly have bidirectional references to > the devices > they are controlling. My current thinking is that routing a peripheral's > interrupt only to the device driver that is directly responsible for it > maintains complete encapsulation but allowing this interrupt to > be arbitrarily > routed to other pieces of software in the system breaks it. > > What I hear you saying, though, is that Embedlets should not be > used as JAPL > device drivers and I can certainly go along with this philosophy > if Embedlets > are blocked from having direct references to JAPL peripherals. > If an Embedlet > is being constrained as only operating as a high level piece of > code then how > can it be ok to give it a direct reference to a low level > peripheral like a > UART? > > Assuming that a JAPL peripheral can not be its own device driver and if > Embedlets are not permitted to be device drivers, then we still > need some kind > of a device driver that is part of the Embedlet framework that can do the > following: > > 1) Hold direct references to JAPL peripherals. > > 2) Accept interrupt events from these peripherals. > > 3) Convert Embedlet events into method calls on the peripheral. > > 4) Convert the peripheral's interrupt events into Embedlet events. > > The current Adapter might be suitable for this purpose and if not > the Adapter > then perhaps an Embedlet Container DeviceDriver? > > > Anyway, I am going to hold off doing more work in this area until > we get this > JAPL issue resolved. Actually I have been hitting JGraph fairly > hard during > the past week in preparation for beginning work on the Wiring > Tool and so I > have plenty to keep me busy. ;-) > > > Ted > > __________________________________________________ > Do you Yahoo!? > Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! > http://platinum.yahoo.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 > |
|
From: Gregg G. W. <gr...@sk...> - 2003-03-31 13:58:20
|
>> I'm feeling dense....what is the reference to? > >heh... I though the americans among us wouldn't get it, but the Ausies and >Canucks would! > >It actually a place name for an area of London (eng.). You will find people >calling places Piccadilly in a lot of english literature,... also a lot of >families with English roots might name places Piccadilly (my onw family does >that at our cottage up on Lake Joseph, and N. Ontario). >Anyway, it reffers to a place "where things come togher" a cross-roads etc. >I thought it apt because I'm trying to bring Outpost and JAPL together ;) And more specifically, it is called Piccadilly Circus, which means that it is a circular path/road where several roads come together and then branch out again. If you have never been there, you'd not think much of it. When I was last there in 1990 and 1991 (on 4 different occasions), it was the place where everything converged in London. The 'tube' (unground subway) stops near there, and brings everyone from outlying areas into the city. The area is probably comparable to the same thing as Time Square in NYC, in terms of entertainment, food and what not. There were many street muscians and other acts hanging around there too. I think Piccadilly is a great name! ----- gr...@cy... (Cyte Technologies Inc) |
|
From: Brill P. <bri...@ro...> - 2003-03-31 13:21:46
|
> >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. See my message (March 29, 2003 1:36 AM) with the subject "Re: [Embedlets-dev] Re: JAPL part of specification". I have attached the current API docs for JAPL (not including the docs for the platform-tini, which is separate). the layout your interested in is: org.japl.peripheral <= contains the generic interfaces org.japl.peripheral.<name> <= contains concrete implementations of some devices (mostly I2C). The device drivers are platform independant, and will run on any platform implementation (e.g. the platform-tini impl). > 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); Thats what I'm asking about ;) I think we're all on the same wavelength, jhust struggeling to understand the different APIs. - Brill Pappin |
|
From: Ted K. <tk...@ya...> - 2003-03-31 06:50:07
|
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 implementing a JAPL interface
and registering itself as a listener for Events coming from a JAPL peripheral
(that it already has a reference to) using this interface 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 (again, there are no
Embedlet dependencies in the JAPL code)?
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 peripheral 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.
>> 4) 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
__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
|
|
From: Brill P. <bri...@ro...> - 2003-03-31 05:46:08
|
> 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 James... the code you would actually have to write is much smaller than you think... thanks to the Link/Pipe architecure. There are a few base classes that you would need to implement (Processor, Port etc. for direct access) and any TransportLink implementations you might need... in your case with the uVM, the minimum would would be the UART link... but you could also do an I2C or API link as well. For instance, the JStamp platform impl. has a total of 4 classes, and that allows a fully working I2C system, with all the drivers availible in the JAPL (I think I've done about 10 or so already, though they are not all tested). You will have an added problem because you have to re-compile everything into native code... but that case I think is unusual, and you may not have a problem at all if it happens automatically, because you only have a few classes that must be native... everything else is pure JAPL. - Brill Pappin |
|
From: Brill P. <bri...@ro...> - 2003-03-31 05:43:12
|
> > 'm thinking that they shouldn't have *any* relationship besides one being able > > to talk to the other. The idea being the separation of the two different APIs > > and their respective domains... > > Exactly my thinking. Which leads to the need for a "mediation" layer, like > the JAPL Wrapper class that I have proposed as a "best practice" programming > paradigm when using both Embedlets and JAPL together. It allows for clean > separation of the two layers. Yes... agreed... this is what piccadilly is sopposed to be... or at least its the first attempt, and will likley find problems in both api's ;) [...] > It would be based on the XML Config files and maybe properties at runtime. I > don't want to put much if any dynamic config information into the runtime > system since that will be a strain on less capable platforms. Many Embedlet > containers will be "pre-compiled" with their components to fit on smaller > platforms like TINI or uVM. Don't count on having a runtime dynamic > interface for wiring. Not a big deal since the wiring tool is a "build time" > activity and would have access to the config information (out of the XML > files) in other ways. Oh, I don't think you need too much in the way of "dynamic" configuration... the way I've been working it, you would have to know what drivers you where going to load... so the outpost contain could report that fairly easily to a client app. once the client knows what the container has, it can control the methods etc of the drivers... however this all implementation dependant, and every one of us could come up with an implementation. In fact, I'd go so far as to say that you don't even really need the JAPL to do this... but japl being what I've been working on, of course I'm going to try and integreate them ;) > > my JAPL to Outpost implementation is "Piccadilly" (some of you > > might understand the reference) and that is what I'm trying to do with it. > > I'm feeling dense....what is the reference to? heh... I though the americans among us wouldn't get it, but the Ausies and Canucks would! It actually a place name for an area of London (eng.). You will find people calling places Piccadilly in a lot of english literature,... also a lot of families with English roots might name places Piccadilly (my onw family does that at our cottage up on Lake Joseph, and N. Ontario). Anyway, it reffers to a place "where things come togher" a cross-roads etc. I thought it apt because I'm trying to bring Outpost and JAPL together ;) > > I think I'm just missing how the IO in the embedlet world is done... I > > haven't had a lot of time lately, but am still plugging away.... > > IO to peripherals would be through the JAPL API's (and using JAPL Wrappers > where needed for async/interrupt driven stuff). Other IO would be done > through Container Services (events, logging, persistence, etc.) or through > appropriate Adapters that link to the outside world. I think my answer to all this is the wrappers... I'll take a look and see what I can come up with... though I might not get to it again until next weekend, and my week days tend to end late. - Brill Pappin |
|
From: Brill P. <bri...@ro...> - 2003-03-31 05:32:30
|
> > An embedlet should be able to register itself as a listener to a JAPL > > event generator > > I strongly disagree. This couples JAPL and Embedlets too much and bypasses > the Embedlet Event scheduling and control mechanisms. Bad idea. If you are > doing that, then why bother with a container? Just write straight Java code > and be done with it. Not to mention cause the JAPL events to grind to a (almost) halt waiting for the Outpost container(s) to do what they need to do!. - Brill Pappin |
|
From: Brill P. <bri...@ro...> - 2003-03-31 05:27:11
|
> My recommendation is that Teds idea of JAPL actually needs to be broken > into 2 layes, APT, JAPL where the APT layer is a completely abstract > interface of Abstract peripherals implemented by the platform and > created by the APT peripheral factory, ie the APT is a wrapper for the > proprietry libries into a common abstract peripheral toolkit. But it already works that way! see: org.japl.peripheral > JAPL then is a shared device driver library that is built ontop of the > APT and so now the JAPL library is platform independent so all japl > devices can run on any platform that supports the APT framework. > > I think the embedlet container implementation should provide an APT > PeripherFactory which is used by embedlets when creating JAPL components > which are implemented by APT components. I don't think you need to integrate the two... embedlet access to the JAPL is done through the Outpost implementation, and leaves it flexible... now that implementation can have references to both... which is kind of the plan anyway. - Brill Pappin |
11 messages has been excluded from this view by a project administrator.
Thanks for helping keep SourceForge clean.
X