Thread: [Embedlets-dev] Re: JAPL Events
Status: Alpha
Brought to you by:
tkosan
Menu
▾
▴
embedlets-developer
|
From: Andrzej J. T. <an...@ch...> - 2003-03-23 21:01:03
|
Ted: > My first thought was to use a JaplEventListener interface that Embedlets > can implement and then the Embedlet instance in question can register as > an event listener to the JAPL device it has a reference to. But of course the > state of an Embedlet is held within a ComponentContext object so how does one > register a ComponentContext object instance as a listener to JAPL events? How are the JAPL events triggered? Interrupt? Polled? If polled, then you can create a small polling embedlet that polls the JAPL device (using the Timer Service) on a regular basis, and then posts a Robot Embedlet Event when something interesting is detected. If Interrupt driven, one way would be to write a Robot JAPL driver routine that implements the EventProducer interface, and have the Robot JAPL driver get/store a reference to the Event Service (there is a static method you can use in Container to get the EventService instance). The driver would then post a suitable Robot Embedlet event (using the EventService to send() the event) when the interrupt triggers. Downstream devices/components should not know what upstream components are "listening" for their events typically, since that produces too much coupling. ComponentContext objects are passive data holders ONLY! They should never be registered as a callback object, since that would imply that they would have to have application logic in them. I would advise against having the JAPL device issue a callback against an Embedlet instance.....since that again couples the two layers a bit too closely. The Event Service is the preferred way to interface two layers together (per the above suggestions). Send an Event, Ted! ;-) Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Andrzej J. T. <an...@ch...> - 2003-03-28 17:54:44
|
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 |
|
From: Ted K. <tk...@ya...> - 2003-03-29 04:57:41
|
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 |
|
From: Brill P. <bri...@ro...> - 2003-03-29 06:53:20
|
> 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. I've taken a slightly different approach to things like UARTS etc. in that they are TransportLinks and not peripherals in them selves. the configuration of a uart is really implementation dependant anyway. The point being that a peripheral would be something that the uart was attached to... using the org.japl.transport package allows the actual link to a peripheral to be transparent and changeable... for instance (though not implemented yet) the I2C/1-Wire/SPI/Serial device or even a specific protocol like SLIP could talk over any TransportLink to any other device. The way it works, is that the Links have a standard interface and are wrapped in a Pipe, in the case of I2C it would be: I2CTransportPipe => I2CTransportLink => I2CPeripheral but it could be I2CTransportPipe => UartTransportLink => UartTransportLink => I2CTransportPipe. the concept isn't fully flushed out, and because I haven't had much time lately (and we just did a cleanup of our CVS tree) some things are not implemented, or are partial... and a *lot* of debugging needs to happen. - Brill |
|
From: James C. <ca...@vi...> - 2003-03-30 16:14:25
|
>The JAPL devices are abstract peripherals, not device drivers. The aproach I am taking is that JAPL are drivers and the APT is the Abstract Peripherals James Caska www.muvium.com uVM - 'Java Bred for Embedded' -----Original Message----- From: emb...@li... [mailto:emb...@li...] On Behalf Of Ted Kosan Sent: Saturday, 29 March 2003 3:58 PM To: emb...@li... Subject: Re: [Embedlets-dev] Re: JAPL Events Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] _______________________________________________ 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: Brill P. <bri...@ro...> - 2003-03-31 05:27:03
|
> >The JAPL devices are abstract peripherals, not device drivers. > > The aproach I am taking is that JAPL are drivers and the APT is the > Abstract Peripherals Don't get me started on this again! ;) JAPL = Java Abstract Peripheral Library I'd love to take a look at your APT though... I wondering if we can incorporate all those interfaces you (may) have written into the JAPL. If your interested, take a look at those javadocs I sent to the list... the contracts would go in "org.japl.peripheral" and there are a few in there already. Most of the JAPL contains drivers as well as the JAPL contracts (I found I had to do that to maintain a clean library) so Cork has become the platform implementation for a particular processor. BTW - If any of you TINI guru's out there want to give me a hand with the TINI impl. I'd be very glad for the help. My TINI experience is limited... I'm also finding the TINI not well thought out when it comes to simple things like control of its port, you can set it, and get it, but that's it! no direction settings, no polarity settings etc... now likely you could skip the TINI port interface, ad use native calls, but I'm not familiar enough yet to try that. Anyway, I've written the OneWireTransportLink for the Tini, but haven't be able to test it yet. - Brill Pappin |
|
From: James C. <ca...@vi...> - 2003-03-30 16:02:02
|
>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 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 |
|
From: Brill P. <bri...@ro...> - 2003-03-31 05:16:36
|
> >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 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. - Brill Pappin |
|
From: Andrzej J. T. <an...@ch...> - 2003-03-30 17:15:41
|
James says: > 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. Better bet is to create a JAPL wrapper class that registers itself to a JAPL event generator and then "translates" JAPL events into Embedlet Events which are sent further upstream. Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: James C. <ca...@vi...> - 2003-03-31 01:21:42
|
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 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. James Caska www.muvium.com uVM - 'Java Bred for Embedded' -----Original Message----- From: emb...@li... [mailto:emb...@li...] On Behalf Of Andrzej Jan Taramina Sent: Monday, 31 March 2003 3:14 AM To: emb...@li... Subject: [Embedlets-dev] Re: JAPL Events Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] _______________________________________________ James says: > 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. Better bet is to create a JAPL wrapper class that registers itself to a JAPL event generator and then "translates" JAPL events into Embedlet Events which are sent further upstream. 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: 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: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: 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: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: Ted K. <tk...@ya...> - 2003-03-24 04:13:09
|
Andrzej,
>How are the JAPL events triggered? Interrupt? Polled?
In the case of RoboCode, the model is definitely interrupt driven. In addition
to this, the RoboCode event objects contain rich semantics that need to be
dealt with. For example, the robocode.ScannedRobotEvent contains these
methods:
double getBearing()
double getBearingRadians()
double getDistance()
double getEnergy()
double getHeading()
double getHeadingRadians()
double getLife()
String getName()
>If Interrupt driven, one way would be to write a Robot JAPL
>driver routine that implements the EventProducer interface,
>and have the Robot JAPL driver get/store a reference to the
>Event Service (there is a static method you can use in Container
>to get the EventService instance). The driver would then post
>a suitable Robot Embedlet event (using the EventService to
>send() the event) when the interrupt triggers. Downstream
>devices/components should not know what upstream components
>are "listening" for their events typically, since that produces
>too much coupling.
Before I posted my initial question I thought about this one a great deal and
what I came up with is that this would require another type of software entity
to be added to the Embedlet framework besides a Adapters, Transports and
Embedlet. Before going this route I thought that we should discuss it and
probably at least try to solve the problem another way.
Apart from this, it appears that the JAPL peripherals are well suited to use
method calls for commands being sent to them and simple callbacks for any
interrupts/events that they might generate.
>I would advise against having the JAPL device issue a callback
>against an Embedlet instance.....since that again couples the
>two layers a bit too closely. The Event Service is the preferred
>way to interface two layers together (per the above suggestions).
>Send an Event, Ted! ;-)
I am all for going with whatever makes sense here and my thinking so far on
this topic is as follows. The Architecture document already shows Embedlets
having direct references to JAPL objects and so far my RoboCode experiments
confirm that this is a good idea. If an Embedlet has a reference to a JAPL
peripheral then it is already closely coupled with it and in my opinion this is
not a problem because the JAPL's abstract nature already provides the required
level of decoupling.
The only thing we are missing now is a way for a JAPL peripheral to send
asynchronous information back to the Embedlet that has a reference to it and
using a simple callback for this purpose seems to solve this problem
adequately. If there is then a need to propagate this information to the reset
of the components in the Embedlet container then the Embedlet that contains the
JAPL peripheral can then translate the JAPL event it received into an Embedlet
event and send it to the container.
It is starting to look like there are going to eventually be thousands of JAPL
peripherals and it is going to be normal for developers to create them
'on-the-fly' just like I am doing with the RoboCode I/O systems. Since most of
a developer's effort will probably be focused on the Embedlets anyway it also
seems like it might be a good idea to have the JAPL related development be
confined to the Embedlets too.
If this line of thinking is followed to its logical conclusion then JAPL
peripherals are completely encapsulated inside of Embedlets and showing them
attached to the periphery of the Embedlet container is not an accurate
depiction.
I suppose that the 'Embedlets having direct references to JAPL peripherals'
model that is shown in the Architecture document is either a good idea or it is
not a good idea. If it is a good idea then I do not see a problem with
completing the connection by allowing the JAPL peripheral to send callbacks to
the Embedlet that contains it. If it is not a good idea then this implies that
Embedlets should not contain direct references to JAPL peripherals at all and
then we will need to come up with another way to solve this problem.
At this point I would vote for exploring the callback model and see how it
plays.
>ComponentContext objects are passive data holders ONLY! They
>should never be registered as a callback object, since that would
>imply that they would have to have application logic in them.
Well, am I correct in assuming that the container only instantiates one
conventional instance of each Embedlet and that the ComponentContext objects
are then used to hold the state of multiple Embedlets? If so, then is it
reasonable to have the one conventional Embedlet instance hold references to
JAPL peripherals (in instance variables) and also register itself for any
callbacks?
I am looking forward to hearing yours and others thoughts on this issue.
Ted
__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
|
Thanks for helping keep SourceForge clean.
X