embedlets-developer Mailing List for Outpost Embedlet Container (Page 23)
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: Holger B. <ho...@bi...> - 2003-02-20 02:37:02
|
>> Differences between Hardware and Software are simply not existent. >> Show >> me the if they exist. >> >> Mostly the hardware today _is_ in fact Software. Not only the >> micrcodes, but in the process of development and construction. I am >> not >> able to construct any thing more complicated than a binkenlight >> without >> Software in it. >> > Agreed that there is a great deal of overlap. The general concept of a > declarative language that generates an operational system is also a > common > theme. As I stated in an earlier post there are a number of synergies. > The > key differences that I have picked up on are: > > 1. The Embedlets specification is about how to package Java objects so > that > they behave like hardware, with defined inputs and outputs, triggers > (events) etc, while retaining an object oriented environment within the > component. This met the behavioral concept in VHDL. > HDL is about generating fast and compact systems from predefined > components > (logical building blocks etc). This maps to the architectural concept of VHDL, the entities. > 2. The Embedlets specification defines extended services that allow > embedded > systems to integrate with enterprise systems, each other and hardware > in > standardized re-usable ways. > > You could do this in HDL but you would have to come up with the same > type of > services and standards. Here met VHDL JHDL. We may take the wave and define services (which i expect mostly FSM are in the so called 'embedded world' - not the fair ;) and standards in a emerging standard way - in pure Java. > 3. The embedlet configurations are based on XML which provides a > parsable, > self documenting, open standards format. uppps, where is the task for providing the schema (xsd) for this? Whithout this, XML degrades to a textfile with '<', '<' and '/'. > HDL is dependent on the 'C' preprocessor and compiler and requires > learning > (yet) another language. Wrong, have a look at the opensourced JHDL project. > The Embedlets space is different and compelling enough to justify a > distinct > specification utilizing enterprise standards and techniques. This is the exact sentence my marketing manager say to me if he want to have it proprietary, not standard compliant, or simply does not know what argument should provide enough power otherwise. Sorry, for being frankly :) > My suggestion is that we look for commonality and areas where > interoperablility is possible. JHDL looks like a move in that > direction. yeap, last sentence. But enough todo even, it is Version 0.3. bax |
|
From: Holger B. <ho...@bi...> - 2003-02-20 02:21:42
|
> I expect to have something to post to CVS, to give us a discussion and > starting point, by this weekend sometime....basically just encoding my > scrawled notes into code (with Javadocs and all the rest, so that we > start > off on the right foot). Does anybody take care of unit tests? "Test before code" policy ?? just for clarification bax |
|
From: Holger B. <ho...@bi...> - 2003-02-20 02:18:42
|
> Andrzej Jan Taramina wrote, On 20/02/2003 0.18: >> Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] >> _______________________________________________ >> bax doth protest with: >>> Differences between Hardware and Software are simply not existent. >>> Show me the if they exist. >> True, but granularity does matter....and hardware is typically a lot >> fine grained than software in that regard. And processor microcode >> is coarser than PLC's or HDL/FPGA and the like. > > It makes me think about the "ladder VS procedural" discussions with > PLC developers ;-) Yes, me too "bull vs. shit". bax > -- > Nicola Ken Barozzi nic...@ap... > - verba volant, scripta manent - > (discussions get forgotten, just code remains) > --------------------------------------------------------------------- > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. > The most comprehensive and flexible code editor you can use. > Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. > www.slickedit.com/sourceforge > _______________________________________________ > Embedlets-developer mailing list > Emb...@li... > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > |
|
From: Holger B. <ho...@bi...> - 2003-02-20 02:17:18
|
> Chris suggests: > >> It may actually make a lot of sense to use a DNS to keep a database >> of ips, >> since that is what they do. It would be especially useful in a large >> installation such as an oil refinery: > > That's true...but the guys deploying the devices may not have the > knowledge > nor access to the corporate DNS servers. And the glass house guys > probably > won't want to implement DNS lookups for thousands of devices. > > Be great if they did though. ;-) > >> There should be a name AND an identity (you may have stated this but >> I just >> wanted to emphasize to point). The name is used for human consumption >> and can >> change, the identity is fixed for the life of the configuration and >> is used >> for internal reference. > > Why not just use a string based identiy that can be used for both? Why do not use a SHA-1 value, use a PKI CA and X.509 certificates and you have with 20 bytes on the device a home-run, i think. Environments for this are already out there (ejbca at sf.net). JAI bax |
|
From: Holger B. <ho...@bi...> - 2003-02-20 02:12:54
|
> bax doth protest with: > >> Differences between Hardware and Software are simply not existent. >> Show >> me the if they exist. > > True, but granularity does matter....and hardware is typically a lot > fine > grained than software in that regard. And processor microcode is > coarser > than PLC's or HDL/FPGA and the like. again, > bax doth protest with: regardless of the granularity, microcode is formulated in HDL's like even a simple inverter. If you would insist, do it on the analogous side of the sensor. Then i will agree, at the moment ;-) >> Software/Hardware is a marketing topic, no more no less. > > I think that is an oversimplification, in the real world. There are > practical implications that lead one to use the tools appropriate to > the > level of granularity that makes sense. Which one? >> One is able to move _any_ functionality from HW into SW and vice >> versa. > > Yes, but just because you can does not imply that you should. ;-) But, that it is industry standard and not only the big player does it, should. It is day by day work for people developing embedded devices, PIC, 8051, ASIC, VLSI AD etc. pp. Nobody will go back and 74er TTL's to implement a logical network in hardware, so shouldn't we do in what will you call Software. bax |
|
From: Holger B. <ho...@bi...> - 2003-02-20 02:05:05
|
> bax responds: > >>> I would let the client provide the auto-gen id code as part of the >>> deployment process. >> >> An interceptor architecture might be helpfull on this ... > > At runtime it might....but much of the naming might be generated at > deployment time, which doesn't require interceptors. That is what i was trying to mention: having a interceptor architecture, even in the deployment phase of life cycle ;-) bax > Andrzej Jan Taramina > Chaeron Corporation: Enterprise System Solutions > http://www.chaeron.com > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. > The most comprehensive and flexible code editor you can use. > Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. > www.slickedit.com/sourceforge > _______________________________________________ > Embedlets-developer mailing list > Emb...@li... > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > |
|
From: Holger B. <ho...@bi...> - 2003-02-20 02:03:05
|
FYI: meanwhile the DNS Server service is deprecated (same like NIS and friends), it make more sense to use an LDAP for this tasks. bax Am Mittwoch, 19.02.03, um 23:52 Uhr (Europe/Budapest) schrieb Christopher Smith: > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > _______________________________________________ > >> >> Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] >> _______________________________________________ >> >> Brill asked and Chris responded: >> >> I don't think this is off topic at all.....components (embedlets, >> services, >> adapters and devices) will need internal names, along with a name for >> the >> Outpost container itself. >> >>> The container should have a unique identity that could be >> concatenated with >>> the embedlet/JAPL id. >>> >>> Since the devices are likely to be at the end of a DNS, it >> would probably make >>> sense to structure the path as a URL: >>> >>> http://targetDevice.mycompany.com:port/containerID/EmbedletID/JAPLID >> >> If a company has thousands of embedded processors deployed, it's >> unlikely >> that they will use DNS names for them, since maintaining that many DNS >> entries is a big task. More likely they will just allocate IP >> addresses. > > It may actually make a lot of sense to use a DNS to keep a database of > ips, > since that is what they do. It would be especially useful in a large > installation such as an oil refinery: > > http://holdingTank114.elsugundo.unionoil.com:8180/tankMonitor/oilLevel > > This assumes that there can be more than one container at a given ip > address, the container address would be omitted if not. > > The address resolution would be distributed to each level of the > hierarchy: > DNS(domain)/IPDaemon(port)/Controller/Container/Embedlet > >> >> That being said, the idea has merit. What I'm planning to put in >> the spec is >> that the user will be able to assign names to all the components and >> the >> container (as strings) in the XML Config files, and in the case of the >> container itself, allow this to be overriden in the deployment >> process (so >> that multiple identical containers can had unique names). But I was >> not >> planning on specifying what the names should look like....would >> rather just >> allow any arbitrary string, and let the client use whatever >> naming standard >> makes sense for them (since they may already have corporate standards >> for >> this). >> > > There should be a name AND an identity (you may have stated this but I > just > wanted to emphasize to point). The name is used for human consumption > and > can change, the identity is fixed for the life of the configuration > and is > used for internal reference. > >> Brill continued: >> >>> Sure... though I wasn't trying to come up with an ID for >> embedlets and it >>> needs to work without an embedlet system present. however that >> is certainly a >>> workable solution. >> >> I'ld be wary of imposing naming conventions, since clients may >> already have >> their own. Just provide a name string, with getName()/setName() >> methods. If >> the JAPL device is running under the control of an Embedlet >> Container, then >> the Embedlet would likely read the device id from the XML config file >> and >> issue the setName() property on the devices behalf. >> >>> Yes, that's pretty much what I'd like to do... what I need to >> decide is how >>> the id is generated etc, and who names the container? >> >> If we provide a generic, string-based naming ability, the client can >> do >> whatever makes sense for them. >> >>> So, the id's can be auto generated during negotiation and >> start-up, or they >>> can be named parameters in some sort of property set... for >> embedlets the >>> named approach makes sense. >> >> I would let the client provide the auto-gen id code as part of >> the deployment >> process. >> >> >> Andrzej Jan Taramina >> Chaeron Corporation: Enterprise System Solutions >> http://www.chaeron.com >> >> >> >> ------------------------------------------------------- >> This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. >> The most comprehensive and flexible code editor you can use. >> Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. >> www.slickedit.com/sourceforge >> _______________________________________________ >> Embedlets-developer mailing list >> Emb...@li... >> https://lists.sourceforge.net/lists/listinfo/embedlets-developer >> > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. > The most comprehensive and flexible code editor you can use. > Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. > www.slickedit.com/sourceforge > _______________________________________________ > Embedlets-developer mailing list > Emb...@li... > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > |
|
From: Christopher S. <cs...@oo...> - 2003-02-20 01:12:10
|
> > > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > _______________________________________________ > > Differences between Hardware and Software are simply not existent. Show > me the if they exist. > > Mostly the hardware today _is_ in fact Software. Not only the > micrcodes, but in the process of development and construction. I am not > able to construct any thing more complicated than a binkenlight without > Software in it. > Agreed that there is a great deal of overlap. The general concept of a declarative language that generates an operational system is also a common theme. As I stated in an earlier post there are a number of synergies. The key differences that I have picked up on are: 1. The Embedlets specification is about how to package Java objects so that they behave like hardware, with defined inputs and outputs, triggers (events) etc, while retaining an object oriented environment within the component. HDL is about generating fast and compact systems from predefined components (logical building blocks etc). 2. The Embedlets specification defines extended services that allow embedded systems to integrate with enterprise systems, each other and hardware in standardized re-usable ways. You could do this in HDL but you would have to come up with the same type of services and standards. 3. The embedlet configurations are based on XML which provides a parsable, self documenting, open standards format. HDL is dependent on the 'C' preprocessor and compiler and requires learning (yet) another language. The Embedlets space is different and compelling enough to justify a distinct specification utilizing enterprise standards and techniques. My suggestion is that we look for commonality and areas where interoperablility is possible. JHDL looks like a move in that direction. > Software/Hardware is a marketing topic, no more no less. > > One is able to move _any_ functionality from HW into SW and vice versa. > > bax > PS: Have a look at Finite State Machines, regarding the parallel thread > - already solved in FSM - Software _and_ Hardware. ... and fundamental > part of VHDL :) > > > Bax clarifies: > > > >> One is able to describe _any_ digital hardwaredevice, including > >> temparature sensors and mainframe computers. You are able to use these > >> bricks in any other construction and combination. HDL has inputs, > >> outputs, > >> events, vectors of bits, vectors of vectors etc. pp. > > > > True....but can it describe any arbitrary software component? That is > > where the difference > > lies....HDL is Hardware Description Language. We are writing a > > container for software > > components...not hardware. There is some commonality, but I think > > it's a stretch at best. > > There may be some concepts we can borrow from HDL, but I doubt the > > syntax will be useful > > as it stands. > > > >> It is _not_ a modeling language, like UML, it is a reality language. > >> Wiring-, Testing-, Simulation- Compilertools are parts of the > >> language. > > > > Is it XML based? Just curious... > > > >> IMHO, if i read the docs of emblets - you are definig a second > >> approach to > >> HDL. The own OutPost HDL. I do not know ... looks like this second > >> invention of the wheel for me. > > > > Nope....we are defining an EDL. Embedlet Description Language, which > > is a subclass of > > SDL (software description language). <grins> > > > > Different beastie altogether, since embedlets will encompass business > > logic at some higher > > level than hardware wiring does. > > > > ...Andrzej > > > > Chaeron Corporation > > http://www.chaeron.com > > > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. > > The most comprehensive and flexible code editor you can use. > > Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. > > www.slickedit.com/sourceforge > > _______________________________________________ > > Embedlets-developer mailing list > > Emb...@li... > > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. > The most comprehensive and flexible code editor you can use. > Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. > www.slickedit.com/sourceforge > _______________________________________________ > Embedlets-developer mailing list > Emb...@li... > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > |
|
From: Andrzej J. T. <an...@ch...> - 2003-02-20 00:47:58
|
Hey Ted: Can we put up a page on the embedlet.org domain....at least a redirect to the sourceforge site (and on any other domains that you have registered)? I've created a license based on the Apache license, and it will refer to www.embedlet.org, so this would be helpful. I've been doodling specs/interfaces, etc. on paper. Created the first Java source code file today....an embedlet lifecycle interface. I'm splitting the source tree into two packages, which will be built independently. 1) org.embedlet which will contain the standard contracts, interfaces and base classes that every Embedlet container and component will have to use, and which will be packaged in an embedlet.jar file (just like the servlet.jar file). 2) org.outpost which will contain the reference implementation of the first container that is implemented. This will obviously use embedlet.jar from the first step. This will give us a clean separation between the spec and the container stuff. Already have Ant build scripts working that will compile, jar, javadoc and package (for distribution) both the embedlet and outpost deliverables. Note...these are build scripts that are intended for use by the developers of the embedlet and outpost code bases, and will be used to create the public distributions (zip files). Users that want to build embedlets and/or use the Outpost container would not use these scripts....they would use the distributions only (since they would not be recompiling the stuff in the embedlet.jar file or the container stuff). Just thought I should clarify this... I expect to have something to post to CVS, to give us a discussion and starting point, by this weekend sometime....basically just encoding my scrawled notes into code (with Javadocs and all the rest, so that we start off on the right foot). Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Nicola K. B. <nic...@ap...> - 2003-02-19 23:45:19
|
Andrzej Jan Taramina wrote, On 20/02/2003 0.18:
> Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
> _______________________________________________
>
> bax doth protest with:
>
>
>>Differences between Hardware and Software are simply not existent. Show
>>me the if they exist.
>
> True, but granularity does matter....and hardware is typically a lot fine
> grained than software in that regard. And processor microcode is coarser
> than PLC's or HDL/FPGA and the like.
It makes me think about the "ladder VS procedural" discussions with PLC
developers ;-)
--
Nicola Ken Barozzi nic...@ap...
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
|
|
From: Andrzej J. T. <an...@ch...> - 2003-02-19 23:18:41
|
Chris suggests: > It may actually make a lot of sense to use a DNS to keep a database of ips, > since that is what they do. It would be especially useful in a large > installation such as an oil refinery: That's true...but the guys deploying the devices may not have the knowledge nor access to the corporate DNS servers. And the glass house guys probably won't want to implement DNS lookups for thousands of devices. Be great if they did though. ;-) > There should be a name AND an identity (you may have stated this but I just > wanted to emphasize to point). The name is used for human consumption and can > change, the identity is fixed for the life of the configuration and is used > for internal reference. Why not just use a string based identiy that can be used for both? Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Andrzej J. T. <an...@ch...> - 2003-02-19 23:18:38
|
bax doth protest with: > Differences between Hardware and Software are simply not existent. Show > me the if they exist. True, but granularity does matter....and hardware is typically a lot fine grained than software in that regard. And processor microcode is coarser than PLC's or HDL/FPGA and the like. > Software/Hardware is a marketing topic, no more no less. I think that is an oversimplification, in the real world. There are practical implications that lead one to use the tools appropriate to the level of granularity that makes sense. > One is able to move _any_ functionality from HW into SW and vice versa. Yes, but just because you can does not imply that you should. ;-) Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Andrzej J. T. <an...@ch...> - 2003-02-19 23:18:34
|
bax responds: > > I would let the client provide the auto-gen id code as part of the > > deployment process. > > An interceptor architecture might be helpfull on this ... At runtime it might....but much of the naming might be generated at deployment time, which doesn't require interceptors. Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Christopher S. <cs...@oo...> - 2003-02-19 22:51:48
|
> > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > _______________________________________________ > > Brill asked and Chris responded: > > I don't think this is off topic at all.....components (embedlets, > services, > adapters and devices) will need internal names, along with a name for the > Outpost container itself. > > > The container should have a unique identity that could be > concatenated with > > the embedlet/JAPL id. > > > > Since the devices are likely to be at the end of a DNS, it > would probably make > > sense to structure the path as a URL: > > > > http://targetDevice.mycompany.com:port/containerID/EmbedletID/JAPLID > > If a company has thousands of embedded processors deployed, it's unlikely > that they will use DNS names for them, since maintaining that many DNS > entries is a big task. More likely they will just allocate IP addresses. It may actually make a lot of sense to use a DNS to keep a database of ips, since that is what they do. It would be especially useful in a large installation such as an oil refinery: http://holdingTank114.elsugundo.unionoil.com:8180/tankMonitor/oilLevel This assumes that there can be more than one container at a given ip address, the container address would be omitted if not. The address resolution would be distributed to each level of the hierarchy: DNS(domain)/IPDaemon(port)/Controller/Container/Embedlet > > That being said, the idea has merit. What I'm planning to put in > the spec is > that the user will be able to assign names to all the components and the > container (as strings) in the XML Config files, and in the case of the > container itself, allow this to be overriden in the deployment > process (so > that multiple identical containers can had unique names). But I was not > planning on specifying what the names should look like....would > rather just > allow any arbitrary string, and let the client use whatever > naming standard > makes sense for them (since they may already have corporate standards for > this). > There should be a name AND an identity (you may have stated this but I just wanted to emphasize to point). The name is used for human consumption and can change, the identity is fixed for the life of the configuration and is used for internal reference. > Brill continued: > > > Sure... though I wasn't trying to come up with an ID for > embedlets and it > > needs to work without an embedlet system present. however that > is certainly a > > workable solution. > > I'ld be wary of imposing naming conventions, since clients may > already have > their own. Just provide a name string, with getName()/setName() > methods. If > the JAPL device is running under the control of an Embedlet > Container, then > the Embedlet would likely read the device id from the XML config file and > issue the setName() property on the devices behalf. > > > Yes, that's pretty much what I'd like to do... what I need to > decide is how > > the id is generated etc, and who names the container? > > If we provide a generic, string-based naming ability, the client can do > whatever makes sense for them. > > > So, the id's can be auto generated during negotiation and > start-up, or they > > can be named parameters in some sort of property set... for > embedlets the > > named approach makes sense. > > I would let the client provide the auto-gen id code as part of > the deployment > process. > > > Andrzej Jan Taramina > Chaeron Corporation: Enterprise System Solutions > http://www.chaeron.com > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. > The most comprehensive and flexible code editor you can use. > Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. > www.slickedit.com/sourceforge > _______________________________________________ > Embedlets-developer mailing list > Emb...@li... > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > |
|
From: Holger B. <ho...@bi...> - 2003-02-19 21:20:09
|
> If a company has thousands of embedded processors deployed, it's > unlikely > that they will use DNS names for them, since maintaining that many DNS > entries is a big task. More likely they will just allocate IP > addresses. > > That being said, the idea has merit. What I'm planning to put in the > spec is > that the user will be able to assign names to all the components and > the > container (as strings) in the XML Config files, and in the case of the > container itself, allow this to be overriden in the deployment process > (so > that multiple identical containers can had unique names). But I was > not > planning on specifying what the names should look like....would rather > just > allow any arbitrary string, and let the client use whatever naming > standard > makes sense for them (since they may already have corporate standards > for > this). This reminds me on the JNDI federated namespace, don't it? > I would let the client provide the auto-gen id code as part of the > deployment > process. An interceptor architecture might be helpfull on this ... bax |
|
From: Holger B. <ho...@bi...> - 2003-02-19 21:16:36
|
Differences between Hardware and Software are simply not existent. Show me the if they exist. Mostly the hardware today _is_ in fact Software. Not only the micrcodes, but in the process of development and construction. I am not able to construct any thing more complicated than a binkenlight without Software in it. Software/Hardware is a marketing topic, no more no less. One is able to move _any_ functionality from HW into SW and vice versa. bax PS: Have a look at Finite State Machines, regarding the parallel thread - already solved in FSM - Software _and_ Hardware. ... and fundamental part of VHDL :) > Bax clarifies: > >> One is able to describe _any_ digital hardwaredevice, including >> temparature sensors and mainframe computers. You are able to use these >> bricks in any other construction and combination. HDL has inputs, >> outputs, >> events, vectors of bits, vectors of vectors etc. pp. > > True....but can it describe any arbitrary software component? That is > where the difference > lies....HDL is Hardware Description Language. We are writing a > container for software > components...not hardware. There is some commonality, but I think > it's a stretch at best. > There may be some concepts we can borrow from HDL, but I doubt the > syntax will be useful > as it stands. > >> It is _not_ a modeling language, like UML, it is a reality language. >> Wiring-, Testing-, Simulation- Compilertools are parts of the >> language. > > Is it XML based? Just curious... > >> IMHO, if i read the docs of emblets - you are definig a second >> approach to >> HDL. The own OutPost HDL. I do not know ... looks like this second >> invention of the wheel for me. > > Nope....we are defining an EDL. Embedlet Description Language, which > is a subclass of > SDL (software description language). <grins> > > Different beastie altogether, since embedlets will encompass business > logic at some higher > level than hardware wiring does. > > ...Andrzej > > Chaeron Corporation > http://www.chaeron.com > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. > The most comprehensive and flexible code editor you can use. > Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. > www.slickedit.com/sourceforge > _______________________________________________ > Embedlets-developer mailing list > Emb...@li... > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > |
|
From: Andrzej J. T. <an...@ch...> - 2003-02-19 21:10:00
|
Brill asked and Chris responded: I don't think this is off topic at all.....components (embedlets, services, adapters and devices) will need internal names, along with a name for the Outpost container itself. > The container should have a unique identity that could be concatenated with > the embedlet/JAPL id. > > Since the devices are likely to be at the end of a DNS, it would probably make > sense to structure the path as a URL: > > http://targetDevice.mycompany.com:port/containerID/EmbedletID/JAPLID If a company has thousands of embedded processors deployed, it's unlikely that they will use DNS names for them, since maintaining that many DNS entries is a big task. More likely they will just allocate IP addresses. That being said, the idea has merit. What I'm planning to put in the spec is that the user will be able to assign names to all the components and the container (as strings) in the XML Config files, and in the case of the container itself, allow this to be overriden in the deployment process (so that multiple identical containers can had unique names). But I was not planning on specifying what the names should look like....would rather just allow any arbitrary string, and let the client use whatever naming standard makes sense for them (since they may already have corporate standards for this). Brill continued: > Sure... though I wasn't trying to come up with an ID for embedlets and it > needs to work without an embedlet system present. however that is certainly a > workable solution. I'ld be wary of imposing naming conventions, since clients may already have their own. Just provide a name string, with getName()/setName() methods. If the JAPL device is running under the control of an Embedlet Container, then the Embedlet would likely read the device id from the XML config file and issue the setName() property on the devices behalf. > Yes, that's pretty much what I'd like to do... what I need to decide is how > the id is generated etc, and who names the container? If we provide a generic, string-based naming ability, the client can do whatever makes sense for them. > So, the id's can be auto generated during negotiation and start-up, or they > can be named parameters in some sort of property set... for embedlets the > named approach makes sense. I would let the client provide the auto-gen id code as part of the deployment process. Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Andrzej J. T. <an...@ch...> - 2003-02-19 20:27:12
|
Damn...somehow my email client (pegasus) embedded a few special
characters and posted as HTML. Sorry about that...reposting with normal
text! ;-(
Chris astutely points out:
> This is what I am refering to as 'reverse chain' because if the
Threshold
> is preceeded by other embedlets such as a calibrator the processing
flow
> is going in reverse, based on demand as opposed to forward based on
> events. The Threshold embedlet is 'demanding' the state of the
embedlet(s)
> that preceed it in the event chain. On startup the preceeding
'producer'
> embedlets will not have been started since the 'consumer' needs to
start
> first!
That is true, but I think there might be other ways of dealing with this
issue (if I understand it correctly). One idea that comes to mind is
having the Threshold embedlet support a couple more "states"....where
the state is "unknown". So in your example, assume that the Threshold
embedlet depends on Calibrator A and B, and needs some initial state info
from these two embedlets before it will consider firing a threshold
event upstream (to actuate something). Threshold would initialize
itself, and keep two extra state properties with initial values as
follows:
CalA_State = unknown;
CalB_State = unknown;
These values being set in it's start method. And it then listens for
events from the two Calibrators.
As CalA executes it's start() method, it checks a device level (possibly
through a JAPL method call) and then posts a CalA event with the value
"va";
Threshold would receive this event and change it's state to:
CalA_State = va;
CalB_State = unknown;
And still doesn't send any upstream events since B is unknown.
Then CalB executes it's start() method, it checks a device level
(possibly through a JAPL method call) and then posts a CalB event with
the value "vb";
Threshold would receive this event and change it's state to:
CalA_State = va;
CalB_State = vb;
At which point it knows the underlying state of both calibrators, and can
make a decision on the basis of the values va/vb and the fact that it
transitioned from an unknown to a fully known state, whether to send the
initial upstream threshold change event.
After that, events drive the process as one would expect (eg. the
Calibrators might be polling devices based on a time, or being handed
JAPL events/interrupts, which would trigger upstream event sends).
By extending the state management in this way, arbitrarily long startup
processes can be handled.
> If every embedlet posts an initial event in its 'start()' method the
> consumers will be firing events base on incomplete information.
Not every embedlet would post an event during start(). In my example
above, the Threshold Embedlet doesn't post any events during start()
(all it does is set up it's state info) since it doesn't yet have the
info it needs. And it won't post it's first event till it has received
updates from both Calibrators (and the values exceed the threshold
parameters per your original example).
Yes...this means that the Threshold Embedlet needs to keep track of such
state issues. It would be nice if that could be automated (maybe it can
be through some declarative approach in the config XML), but if it
depends on info from two other components, then somehow it will have to
track this till it receives both updates and can proceed. The solution
requires both event and state management on the part of the Threshold
embedlet, even during it's lengthy "startup" process (which only begins
in the start() method, and then is driven to completion by event
processing).
This solution does require some thought on the part of the Embedlet
developer...but we can probably handle that with examples and
prescriptions for how to do such initialization. Embedlet design best
practices, if you will. It does require using an event-oriented mindset
when thinking about intialization processes. Not sure there is any easy
way around that.
There may be other ways to solve this besides the one I have proposed
above. Be great if there were some other options....
> The OopScope OPC container does what you have proposed (minus the
reverse
> chain):
You've prompted some thinking on my part regarding dependencies and
startup sequences....see below in response to your 2nd email.
> This straight-forward method has run into the stumbling block that I
> outlined, both with boolean and numeric processing. I have worked
around
> it by making critical logic flows level sensitive, driven by a timer so
> that an event is generated every timer cycle. This bypasses the
> efficiencies of an event driven system, however.
As you said, this eliminates much of the value of an event driven system,
so I am reluctant to take that approach (basically, you're layering a
procedural limitation on the event manager instead of using the event
paradigm coupled with state management to handle the extended
intialization).
> I am thinking that embedlets that are 'Inputs' need to have a
> checkInitailConditions() method that is called prior to start(). This
> would allow input embedlets to stage an event to fire when started
based
> on the expected state of the input relative to actual. Or maybe this is
> just built into the start() method of inputs and is a documented not
> enforced behavior.
That just splits the start() method into two pieces which really doesn't
solve the problem. If you think about the Threshold example (using 2
Calibrators), it needs info from both of the components it is dependent
on before it knows whether it should even issue an event (to start
material flow). If the calibrators return values that say the material
hoppers are still adequately full, then the Threshold embedlet should
not send any events, right? So I'm not sure why we need to "stage" an
event which may be invalidated by later input? Maybe I'm just confused
and don't understand the scenario you are thinking of?
> The 'initial' state needs to be considered before events can operate! A
> switch may have tripped before the embedded processor was powered up, a
bank
> account may have funds before the application was installed....
Absolutely! But there is nothing wrong with adding an "unknown" state
(as per my example) to track whether you have received "initial" state
info from a downstream component. In fact, I think this is the
preferred paradigm when using an event driven model. If you can check
the state directly (eg. if Threshold talks directly to a device using
JAPL rather than through intermediary embedlets like the Calibrators),
then you can handle it all in the start() method. It only gets
complicated if you link longer chains of dependent Embedlets together,
and when an embedlet depends on more than one downstream component.
I'm not sure what you are proposing to solve this "reverse chain" issue?
Or dores my example above resolve the issue?
> The state (in the simplest case) is the value of a switch input or the
> result of a boolean operation on several inputs. It would not seem to
make
> sense to store this in any place other than the processing component -
the
> embedlet.
I agree....and my example does exactly that, across multiple dependent
embedlets. The only "additional" state that needs maintaining is
startup state on the part of the dependent component (Threshold
embedlet) so that it can figure out when it has received all the intial
state info from it's downstream embedlets. After that, it can ignore
this state and just respond to incoming events if that is appropriate to
it's function.
> The model for this is digital logic: Gates are state driven,
> latches are event driven or synchronized by a clock. They co-exist, but
the
> designer has to be aware of initial conditions, race conditions etc.
Exactly my point! The two Calibrator embedlets (in the example) are akin
to state-driven gates, whereas the Threshold embedlet would be more like
an event-driven latch. The key point, just as in the digital logic
area, the embedlet developer has to be aware of intial and race
conditions too! I'ld love to see a way around this, but without
butchering the architecture unecessarily, I haven't thought of a way
yet.
> Moving the state outside of the 'visible' embedlet realm seems
artificial
> and unneccesary.
Not sure what you mean by this? The Embedlet Context (which will hold
the state info) will be unique to the particular embedlet.....the fact
that we won't use instance variables to hold state (for which there are
very good reasons), really is just a design artifact, since the
combination of the embedlet instance and it's unique context object make
up an "embedlet" which encompasses both process (logic) and state
(context).
> Some embedlets will be state driven and some event driven.
> OR they may need to to function in a mixed environment.
Sounds to me like those embedlets that talk directly to the hardware
(through JAPL or directly) would be primarily state driven, and that all
upstream embedlets would be event driven (for the most part). Mightl
end up being a "best practice" to not create embedlets that do both.
Even so, one could look at changes in the device as being "events" of a
type.
Maybe I'm just tripping up on your use of the terms "state" in this
context. Some embedlets will just react to events and will not need to
keep track of prior state (in that regard, the "state" information is
completely encapsulated in the event they receive). Others might need
to track internal state info (as the Threshold does during startup). I'm
not sure why you see this as an issue?
> My initial point was that there ARE mixed paradigms that need to co-
exist
> (my use of 'vs' was a little misleading).
OK....dropping the "versus" helps me understand a bit. I do agree that
we will need to be able to support any combination of event and state
capabilities. I think the architecture allows for this already (per my
example).
> The solution that I am striving
> for would have to accomodate both in a way that does not create
mutually
> exclusive requirements, indeterminate initial values or race
conditions.
My gut feel is that we won't be able to fully automate the handling of
all these situations (especially in the first few releases, though we
may come up with creative solutions down the road), and that the
responsibility will devolve onto the Embedlet developer to account for
such and handle them properly. With some guidance, examples, tutorials
and the like from us.
If you have an idea on how we could handle these things in the container,
automatically, I'm all ears! ;-)
> Maybe it is as simple as providing a mechanism for initial conditions
to
> propagate forward on start up. This would limit the requirement for
'reverse
> chain logic' where an output has to 'look' all the way back into the
logical
> tree to determine a correct value. It would only have to wait for an
event
> and then 'look' at the immediate nodes and assume that they were
current.
I think the architecture already provides this capability. But it does
require some thought and "state management" code on the part of the
embedlet developer.
The concept of "reverse chain logic" where an upstream component has to
procedurally tap the components it's dependent on will compromise
modularity way too much, since it promotes tightly coupled chains of
embedlets.
> The problem that I see with this is that if an output is dependent on
> several inputs each of which generates an initial event, the output
could
> change for each event, causing quite a bit of consternation in the
chocolate
> factory.
So you write a bit of stateful logic that ensures that this doesn't
happen.....that the Output component doesn't propagate any changes till
it has received all of it's inputs. It's not that hard to do, as I
think my example shows.
> Hence my earlier suggestion of an initialConditions() method prior to
> start(). This would allow initial conditions to propagate and settle
prior
> to asserting any outputs. The lifecycle sequence would then be:
>
> 1. constructor() - the embedlet constructor
> 2. addListener() - wire them together
> 3. initialize() - get ready, configure hardware/JAPL
> 4. initialConditions() - inputs fire initial events, outputs settle
> 5. start() - outputs asserted, inputs start generating change events
> 6. stop() - shut down event generation
> 7. terminate() - clean up your mess
This lifecycle doesn't add anything to the equation, in my mind. The key
is "outputs settle"! If we think about what that means, it's that the
correct/final output result cannot be determined until you receive ALL
necessary initial input events. Since events arrive asynchronously (and
not in any guaranteed order), this means the output has to "wait" till
all it's inputs are in...which in turn implies it has to maintain some
state information as to what has arrived and what is yet to come. In
which case, you might as well simplify the lifecycle and put the startup
state management logic in the start() method, since putting it in a
different method doesn't add anything much.
This "intialization state management logic" is application specific, and
may not be automatically manageable by the container. The only way I
see that it could be accomplished is to declaratively specify in the
application outpost.xml config fie that a particular embedlets (eg.
Threshold) start() method should not be invoked until specific events
had been posted (one from each Calibrator), and then the container would
aggregate these events into one super initialization event that would be
passed in to the start() method.
What I don't like about this is that the developer still has to write a
complex start() method that is not that much simpler than the
event/state drive approach (in my example), so there is not a lot of
benefit. The container gets a lot more complicated as does the config
XML which is probably more complex than the simple state management
logic that might otherwise be required. And most of all, the container
has to convert the event-based paradigm into a procedural one, which is
ugly, and forces the developer to deal with two paradigms instead of
just one. So I wouldn't recommend this approach.
The lifecycle I think that is emerging from all this looks something like
this, for a particular embedlet's perspective:
1. constructor() - the embedlet constructor
2. initialize() - get ready, configure hardware/JAPL
3. addListener() - wire them together (this is transparent to the
embedlet...the container will
do it on its behalf, so it's not a method call on the embedlet)
4. start() - do any startup stuff you need, including managing state or
issuing initialization
events
5. stop() - shut down event generation
6. terminate() - clean up your mess
Note that the addListener should be done by the Container, on the
embedlets behalf, prior to the start() since if an embedlet posts an
event during the start() method, it could end up generating an event (in
an already started embedlet) that the original embedlet should receive
(this is circular, but might be valid in some circumstances). Either
that or we ensure that no posted events are propagated till the start()
method has completed (which might be tricky in a threaded environment or
with synchronous events).
However, this lifecycle should probably be a bit different from the
Container's perspective!
The container would perform steps 1 & 2 for all components, in dependency
sequence. So if your embedlet specified that it was dependent on others
(eg. Threshold is dependent on Calibrator), then Calibrators would go
through 1 & 2 before Threshold went through 1&2. This way, an embedlet
knows that all it's dependencies have been initialized (but not started)
when it's initialize() method is called (and it can thus check for
existence, various context parameters, etc. of it's dependencies, if it
needs/wants to).
Then the container would do 3 & 4 in event consumer/producer order. That
is, it would start all event consumers before event producers for any
particular event. This makes sure that if a producer posts an event in
it's start() method (event posting would be prohibited in the
initialize() method) it is guaranteed that consumers are already
listening.
I think there will be value in having these two lifecycle sequences (from
the containers perspective, one based on dependency and the other based
on event consumer/producer ordering) as we dive into the container
implementation.
Does this make sense, or am I missing some fine points in your argument
that I didn't read between the lines well enough?
...Andrzej
Chaeron Corporation
http://www.chaeron.com
|
|
From: Andrzej J. T. <an...@ch...> - 2003-02-19 20:22:17
|
Bax clarifies: > One is able to describe _any_ digital hardwaredevice, including > temparature sensors and mainframe computers. You are able to use these > bricks in any other construction and combination. HDL has inputs, outputs, > events, vectors of bits, vectors of vectors etc. pp. True....but can it describe any arbitrary software component? That is where the difference lies....HDL is Hardware Description Language. We are writing a container for software components...not hardware. There is some commonality, but I think it's a stretch at best. There may be some concepts we can borrow from HDL, but I doubt the syntax will be useful as it stands. > It is _not_ a modeling language, like UML, it is a reality language. > Wiring-, Testing-, Simulation- Compilertools are parts of the language. Is it XML based? Just curious... > IMHO, if i read the docs of emblets - you are definig a second approach to > HDL. The own OutPost HDL. I do not know ... looks like this second > invention of the wheel for me. Nope....we are defining an EDL. Embedlet Description Language, which is a subclass of SDL (software description language). <grins> Different beastie altogether, since embedlets will encompass business logic at some higher level than hardware wiring does. ...Andrzej Chaeron Corporation http://www.chaeron.com |
|
From: Andrzej J. T. <an...@ch...> - 2003-02-19 20:15:58
|
<?xml version="1.0" ?><html> <head> <title></title> </head> <body> <div align="left"><font face="Arial"><span style="font-size:10pt">Chris astutely points out:</span></font></div> <div align="left"><br/> </div> <div align="left"><font face="Arial" color="#7f7f7f"><span style="font-size:10pt">> This is what I am refering to as 'reverse chain' because if the Threshold</span></font></div> <div align="left"><font face="Arial" color="#7f7f7f"><span style="font-size:10pt">> is preceeded by other embedlets such as a calibrator the processing flow</span></font></div> <div align="left"><font face="Arial" color="#7f7f7f"><span style="font-size:10pt">> is going in reverse, based on demand as opposed to forward based on</span></font></div> <div align="left"><font face="Arial" color="#7f7f7f"><span style="font-size:10pt">> events. The Threshold embedlet is 'demanding' the state of the embedlet(s)</span></font></div> <div align="left"><font face="Arial" color="#7f7f7f"><span style="font-size:10pt">> that preceed it in the event chain. On startup the preceeding 'producer'</span></font></div> <div align="left"><font face="Arial" color="#7f7f7f"><span style="font-size:10pt">> embedlets will not have been started since the 'consumer' needs to start</span></font></div> <div align="left"><font face="Arial" color="#7f7f7f"><span style="font-size:10pt">> first!</span></font></div> <div align="left"><br/></div> <div align="left"><font face="Arial"><span style="font-size:10pt">That is true, but I think there might be other ways of dealing with this issue (if I understand it correctly).  One idea that comes to mind is having the Threshold embedlet support a couple more "states"....where the state is "unknown".  So in your example, assume that the Threshold embedlet depends on Calibrator A and B, and needs some initial state info from these two embedlets before it will consider firing a threshold event upstream (to actuate something).  Threshold would initialize itself, and keep two extra state properties with initial values as follows:  </span></font></div> <div align="left"><br/> </div> <div align="left"><font face="Arial"><span style="font-size:10pt">CalA_State = unknown;</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">CalB_State = unknown;</span></font></div> <div align="left"><br/> </div> <div align="left"><font face="Arial"><span style="font-size:10pt">These values being set in it's start method.  And it then listens for events from the two Calibrators.</span></font></div> <div align="left"><br/> </div> <div align="left"><font face="Arial"><span style="font-size:10pt">As CalA executes it's start() method, it checks a device level (possibly through a JAPL method call) and then posts a CalA event with the value "va";</span></font></div> <div align="left"><br/> </div> <div align="left"><font face="Arial"><span style="font-size:10pt">Threshold would receive this event and change it's state to:</span></font></div> <div align="left"><br/> </div> <div align="left"><font face="Arial"><span style="font-size:10pt">CalA_State = va;</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">CalB_State = unknown;</span></font></div> <div align="left"><br/> </div> <div align="left"><font face="Arial"><span style="font-size:10pt">And still doesn't send any upstream events since B is unknown.</span></font></div> <div align="left"><br/> </div> <div align="left"><font face="Arial"><span style="font-size:10pt">Then CalB executes it's start() method, it checks a device level (possibly through a JAPL method call) and then posts a CalB event with the value "vb";</span></font></div> <div align="left"><br/> </div> <div align="left"><font face="Arial"><span style="font-size:10pt">Threshold would receive this event and change it's state to:</span></font></div> <div align="left"><br/> </div> <div align="left"><font face="Arial"><span style="font-size:10pt">CalA_State = va;</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">CalB_State = vb;</span></font></div> <div align="left"><br/> </div> <div align="left"><font face="Arial"><span style="font-size:10pt">At which point it knows the underlying state of both calibrators, and can make a decision on the basis of the values va/vb and the fact that it transitioned from an unknown to a fully known state, whether to send the initial upstream threshold change event.</span></font></div> <div align="left"><br/> </div> <div align="left"><font face="Arial"><span style="font-size:10pt">After that, events drive the process as one would expect (eg. the Calibrators might be polling devices based on a time, or being handed JAPL events/interrupts, which would trigger upstream event sends).</span></font></div> <div align="left"><br/> </div> <div align="left"><font face="Arial"><span style="font-size:10pt">By extending the state management in this way, arbitrarily long startup processes can be handled.</span></font></div> <div align="left"><br/> </div> <div align="left"><font face="Arial" color="#7f7f7f"><span style="font-size:10pt">> If every embedlet posts an initial event in its 'start()' method the</span></font></div> <div align="left"><font face="Arial" color="#7f7f7f"><span style="font-size:10pt">> consumers will be firing events base on incomplete information.</span></font></div> <div align="left"><br/></div> <div align="left"><font face="Arial"><span style="font-size:10pt">Not every embedlet would post an event during start().  In my example above, the Threshold Embedlet doesn't post any events during start() (all it does is set up it's state info) since it doesn't yet have the info it needs.  And it won't post it's first event till it has received updates from both Calibrators (and the values exceed the threshold parameters per your original example).</span></font></div> <div align="left"><br/> </div> <div align="left"><font face="Arial"><span style="font-size:10pt">Yes...this means that the Threshold Embedlet needs to keep track of such state issues.  It would be nice if that could be automated (maybe it can be through some declarative approach in the config XML), but if it depends on info from two other components, then somehow it will have to track this till it receives both updates and can proceed.  The solution requires both event and state management on the part of the Threshold embedlet, even during it's lengthy "startup" process (which only begins in the start() method, and then is driven to completion by event processing).</span></font></div> <div align="left"><br/> </div> <div align="left"><font face="Arial"><span style="font-size:10pt">This solution does require some thought on the part of the Embedlet developer...but we can probably handle that with examples and prescriptions for how to do such initialization. Embedlet design best practices, if you will.  It does require using an event-oriented mindset when thinking about intialization processes.  Not sure there is any easy way around that.</span></font></div> <div align="left"><br/> </div> <div align="left"><font face="Arial"><span style="font-size:10pt">There may be other ways to solve this besides the one I have proposed above.  Be great if there were some other options....</span></font></div> <div align="left"><br/> </div> <div align="left"><font face="Arial" color="#7f7f7f"><span style="font-size:10pt">> The OopScope OPC container does what you have proposed (minus the reverse</span></font></div> <div align="left"><font face="Arial" color="#7f7f7f"><span style="font-size:10pt">> chain):</span></font></div> <div align="left"><br/></div> <div align="left"><font face="Arial"><span style="font-size:10pt">You've prompted some thinking on my part regarding dependencies and startup sequences....see below in response to your 2nd email.</span></font></div> <div align="left"><br/></div> <div align="left"><font face="Arial" color="#7f7f7f"><span style="font-size:10pt">> This straight-forward method has run into the stumbling block that I</span></font></div> <div align="left"><font face="Arial" color="#7f7f7f"><span style="font-size:10pt">> outlined, both with boolean and numeric processing. I have worked around</span></font></div> <div align="left"><font face="Arial" color="#7f7f7f"><span style="font-size:10pt">> it by making critical logic flows level sensitive, driven by a timer so</span></font></div> <div align="left"><font face="Arial" color="#7f7f7f"><span style="font-size:10pt">> that an event is generated every timer cycle. This bypasses the</span></font></div> <div align="left"><font face="Arial" color="#7f7f7f"><span style="font-size:10pt">> efficiencies of an event driven system, however.</span></font></div> <div align="left"><br/></div> <div align="left"><font face="Arial"><span style="font-size:10pt">As you said, this eliminates much of the value of an event driven system, so I am reluctant to take that approach (basically, you're layering a procedural limitation on the event manager instead of using the event paradigm coupled with state management to handle the extended intialization).</span></font></div> <div align="left"><br/></div> <div align="left"><font face="Arial" color="#7f7f7f"><span style="font-size:10pt">> I am thinking that embedlets that are 'Inputs' need to have a</span></font></div> <div align="left"><font face="Arial" color="#7f7f7f"><span style="font-size:10pt">> checkInitailConditions() method that is called prior to start(). This</span></font></div> <div align="left"><font face="Arial" color="#7f7f7f"><span style="font-size:10pt">> would allow input embedlets to stage an event to fire when started based</span></font></div> <div align="left"><font face="Arial" color="#7f7f7f"><span style="font-size:10pt">> on the expected state of the input relative to actual. Or maybe this is</span></font></div> <div align="left"><font face="Arial" color="#7f7f7f"><span style="font-size:10pt">> just built into the start() method of inputs and is a documented not</span></font></div> <div align="left"><font face="Arial" color="#7f7f7f"><span style="font-size:10pt">> enforced behavior.</span></font></div> <div align="left"><br/></div> <div align="left"><font face="Arial"><span style="font-size:10pt">That just splits the start() method into two pieces which really doesn't solve the problem.  If you think about the Threshold example (using 2 Calibrators), it needs info from both of the components it is dependent on before it knows whether it should even issue an event (to start material flow).  If the calibrators return values that say the material hoppers are still adequately full, then the Threshold embedlet should not send any events, right?  So I'm not sure why we need to "stage" an event which may be invalidated by later input?  Maybe I'm just confused and don't understand the scenario you are thinking of?</span></font></div> <div align="left"><br/></div> <div align="left"><font face="Arial" color="#7f7f7f"><span style="font-size:10pt">> The 'initial' state needs to be considered before events can operate! A</span></font></div> <div align="left"><font face="Arial" color="#7f7f7f"><span style="font-size:10pt">> switch may have tripped before the embedded processor was powered up, a bank</span></font></div> <div align="left"><font face="Arial" color="#7f7f7f"><span style="font-size:10pt">> account may have funds before the application was installed....</span></font></div> <div align="left"><br/> </div> <div align="left"><font face="Arial"><span style="font-size:10pt">Absolutely!  But there is nothing wrong with adding an "unknown" state (as per my example) to track whether you have received "initial" state info from a downstream component.  In fact, I think this is the preferred paradigm when using an event driven model.  If you can check the state directly (eg. if Threshold talks directly to a device using JAPL rather than through intermediary embedlets like the Calibrators), then you can handle it all in the start() method. It only gets complicated if you link longer chains of dependent Embedlets together, and when an embedlet depends on more than one downstream component.</span></font></div> <div align="left"><br/> </div> <div align="left"><font face="Arial"><span style="font-size:10pt">I'm not sure what you are proposing to solve this "reverse chain" issue?  Or dores my example above resolve the issue?</span></font></div> <div align="left"><br/></div> <div align="left"><font face="Arial" color="#7f7f7f"><span style="font-size:10pt">> The state (in the simplest case) is the value of a switch input or the</span></font></div> <div align="left"><font face="Arial" color="#7f7f7f"><span style="font-size:10pt">> result of a boolean operation on several inputs. It would not seem to make</span></font></div> <div align="left"><font face="Arial" color="#7f7f7f"><span style="font-size:10pt">> sense to store this in any place other than the processing component - the</span></font></div> <div align="left"><font face="Arial" color="#7f7f7f"><span style="font-size:10pt">> embedlet. </span></font></div> <div align="left"><br/></div> <div align="left"><font face="Arial"><span style="font-size:10pt">I agree....and my example does exactly that, across multiple dependent embedlets.  The only "additional" state that needs maintaining is startup state on the part of the dependent component (Threshold embedlet) so that it can figure out when it has received all the intial state info from it's downstream embedlets.  After that, it can ignore this state and just respond to incoming events if that is appropriate to it's function. </span></font></div> <div align="left"><br/> </div> <div align="left"><font face="Arial"><span style="font-size:10pt">> The model for this is digital logic: Gates are state driven,</span></font></div> <div align="left"><font face="Arial" color="#7f7f7f"><span style="font-size:10pt">> latches are event driven or synchronized by a clock. They co-exist, but the</span></font></div> <div align="left"><font face="Arial" color="#7f7f7f"><span style="font-size:10pt">> designer has to be aware of initial conditions, race conditions etc.</span></font></div> <div align="left"><br/></div> <div align="left"><font face="Arial"><span style="font-size:10pt">Exactly my point!  The two Calibrator embedlets (in the example) are akin to state-driven gates, whereas the Threshold embedlet would be more like an event-driven latch.  The key point, just as in the digital logic area, the embedlet developer has to be aware of intial and race conditions too!  I'ld love to see a way around this, but without butchering the architecture unecessarily, I haven't thought of a way yet.</span></font></div> <div align="left"><br/></div> <div align="left"><font face="Arial" color="#7f7f7f"><span style="font-size:10pt">> Moving the state outside of the 'visible' embedlet realm seems artificial</span></font></div> <div align="left"><font face="Arial" color="#7f7f7f"><span style="font-size:10pt">> and unneccesary. </span></font></div> <div align="left"><br/></div> <div align="left"><font face="Arial"><span style="font-size:10pt">Not sure what you mean by this?  The Embedlet Context (which will hold the state info) will be unique to the particular embedlet.....the fact that we won't use instance variables to hold state (for which there are very good reasons), really is just a design artifact, since the combination of the embedlet instance and it's unique context object make up an "embedlet" which encompasses both process (logic) and state (context).</span></font></div> <div align="left"><br/> </div> <div align="left"><font face="Arial"><span style="font-size:10pt">> Some embedlets will be state driven and some event driven.</span></font></div> <div align="left"><font face="Arial" color="#7f7f7f"><span style="font-size:10pt">> OR they may need to to function in a mixed environment.</span></font></div> <div align="left"><br/> </div> <div align="left"><font face="Arial"><span style="font-size:10pt">Sounds to me like those embedlets that talk directly to the hardware (through JAPL or directly) would be primarily state driven, and that all upstream embedlets would be event driven (for the most part).  Mightl end up being a "best practice" to not create embedlets that do both. Even so, one could look at changes in the device as being "events" of a type.  </span></font></div> <div align="left"><br/> </div> <div align="left"><font face="Arial"><span style="font-size:10pt">Maybe I'm just tripping up on your use of the terms "state" in this context.  Some embedlets will just react to events and will not need to keep track of prior state (in that regard, the "state" information is completely encapsulated in the event they receive).  Others might need to track internal state info (as the Threshold does during startup).  I'm not sure why you see this as an issue?</span></font></div> <div align="left"><br/></div> <div align="left"><font face="Arial" color="#7f7f7f"><span style="font-size:10pt">> My initial point was that there ARE mixed paradigms that need to co-exist</span></font></div> <div align="left"><font face="Arial" color="#7f7f7f"><span style="font-size:10pt">> (my use of 'vs' was a little misleading). </span></font></div> <div align="left"><br/></div> <div align="left"><font face="Arial"><span style="font-size:10pt">OK....dropping the "versus" helps me understand a bit.  I do agree that we will need to be able to support any combination of event and state capabilities.  I think the architecture allows for this already (per my example).</span></font></div> <div align="left"><br/> </div> <div align="left"><font face="Arial"><span style="font-size:10pt">> The solution that I am striving</span></font></div> <div align="left"><font face="Arial" color="#7f7f7f"><span style="font-size:10pt">> for would have to accomodate both in a way that does not create mutually</span></font></div> <div align="left"><font face="Arial" color="#7f7f7f"><span style="font-size:10pt">> exclusive requirements, indeterminate initial values or race conditions.</span></font></div> <div align="left"><br/> </div> <div align="left"><font face="Arial"><span style="font-size:10pt">My gut feel is that we won't be able to fully automate the handling of all these situations (especially in the first few releases, though we may come up with creative solutions down the road), and that the responsibility will devolve onto the Embedlet developer to account for such and handle them properly.  With some guidance, examples, tutorials and the like from us.</span></font></div> <div align="left"><br/> </div> <div align="left"><font face="Arial"><span style="font-size:10pt">If you have an idea on how we could handle these things in the container, automatically, I'm all ears!  ;-)</span></font></div> <div align="left"><br/></div> <div align="left"><font face="Arial" color="#7f7f7f"><span style="font-size:10pt">> Maybe it is as simple as providing a mechanism for initial conditions to</span></font></div> <div align="left"><font face="Arial" color="#7f7f7f"><span style="font-size:10pt">> propagate forward on start up. This would limit the requirement for 'reverse</span></font></div> <div align="left"><font face="Arial" color="#7f7f7f"><span style="font-size:10pt">> chain logic' where an output has to 'look' all the way back into the logical</span></font></div> <div align="left"><font face="Arial" color="#7f7f7f"><span style="font-size:10pt">> tree to determine a correct value. It would only have to wait for an event</span></font></div> <div align="left"><font face="Arial" color="#7f7f7f"><span style="font-size:10pt">> and then 'look' at the immediate nodes and assume that they were current.</span></font></div> <div align="left"><br/></div> <div align="left"><font face="Arial"><span style="font-size:10pt">I think the architecture already provides this capability.  But it does require some thought and "state management" code on the part of the embedlet developer.</span></font></div> <div align="left"><br/> </div> <div align="left"><font face="Arial"><span style="font-size:10pt">The concept of "reverse chain logic" where an upstream component has to procedurally tap the components it's dependent on will compromise modularity way too much, since it promotes tightly coupled chains of embedlets.  </span></font></div> <div align="left"><br/></div> <div align="left"><font face="Arial" color="#7f7f7f"><span style="font-size:10pt">> The problem that I see with this is that if an output is dependent on</span></font></div> <div align="left"><font face="Arial" color="#7f7f7f"><span style="font-size:10pt">> several inputs each of which generates an initial event, the output could</span></font></div> <div align="left"><font face="Arial" color="#7f7f7f"><span style="font-size:10pt">> change for each event, causing quite a bit of consternation in the chocolate</span></font></div> <div align="left"><font face="Arial" color="#7f7f7f"><span style="font-size:10pt">> factory.</span></font></div> <div align="left"><br/></div> <div align="left"><font face="Arial"><span style="font-size:10pt">So you write a bit of stateful logic that ensures that this doesn't happen.....that the Output component doesn't propagate any changes till it has received all of it's inputs.  It's not that hard to do, as I think my example shows.</span></font></div> <div align="left"><br/></div> <div align="left"><font face="Arial" color="#7f7f7f"><span style="font-size:10pt">> Hence my earlier suggestion of an initialConditions() method prior to</span></font></div> <div align="left"><font face="Arial" color="#7f7f7f"><span style="font-size:10pt">> start(). This would allow initial conditions to propagate and settle prior</span></font></div> <div align="left"><font face="Arial" color="#7f7f7f"><span style="font-size:10pt">> to asserting any outputs. The lifecycle sequence would then be:</span></font></div> <div align="left"><font face="Arial" color="#7f7f7f"><span style="font-size:10pt">> </span></font></div> <div align="left"><font face="Arial" color="#7f7f7f"><span style="font-size:10pt">> 1. constructor() - the embedlet constructor</span></font></div> <div align="left"><font face="Arial" color="#7f7f7f"><span style="font-size:10pt">> 2. addListener() - wire them together</span></font></div> <div align="left"><font face="Arial" color="#7f7f7f"><span style="font-size:10pt">> 3. initialize() - get ready, configure hardware/JAPL</span></font></div> <div align="left"><font face="Arial" color="#7f7f7f"><span style="font-size:10pt">> 4. initialConditions() - inputs fire initial events, outputs settle</span></font></div> <div align="left"><font face="Arial" color="#7f7f7f"><span style="font-size:10pt">> 5. start() - outputs asserted, inputs start generating change events</span></font></div> <div align="left"><font face="Arial" color="#7f7f7f"><span style="font-size:10pt">> 6. stop() - shut down event generation</span></font></div> <div align="left"><font face="Arial" color="#7f7f7f"><span style="font-size:10pt">> 7. terminate() - clean up your mess</span></font></div> <div align="left"><br/> </div> <div align="left"><font face="Arial"><span style="font-size:10pt">This lifecycle doesn't add anything to the equation, in my mind.  The key is "outputs settle"! If we think about what that means, it's that the correct/final output result cannot be determined until you receive ALL necessary initial input events.  Since events arrive asynchronously (and not in any guaranteed order), this means the output has to "wait" till all it's inputs are in...which in turn implies it has to maintain some state information as to what has arrived and what is yet to come. In which case, you might as well simplify the lifecycle and put the startup state management logic in the start() method, since putting it in a different method doesn't add anything much.</span></font></div> <div align="left"><br/> </div> <div align="left"><font face="Arial"><span style="font-size:10pt">This "intialization state management logic" is application specific, and may not be automatically manageable by the container.  The only way I see that it could be accomplished is to declaratively specify in the application outpost.xml config fie that a particular embedlets (eg. Threshold) start() method should not be invoked until specific events had been posted (one from each Calibrator), and then the container would aggregate these events into one super initialization event that would be passed in to the start() method.</span></font></div> <div align="left"><br/> </div> <div align="left"><font face="Arial"><span style="font-size:10pt">What I don't like about this is that the developer still has to write a complex start() method that is not that much simpler than the event/state drive approach (in my example), so there is not a lot of benefit.  The container gets a lot more complicated as does the config XML which is probably more complex than the simple state management logic that might otherwise be required.  And most of all, the container has to convert the event-based paradigm into a procedural one, which is ugly, and forces the developer to deal with two paradigms instead of just one.  So I wouldn't recommend this approach.</span></font></div> <div align="left"><br/> </div> <div align="left"><font face="Arial"><span style="font-size:10pt">The lifecycle I think that is emerging from all this looks something like this, for a particular embedlet's perspective:</span></font></div> <div align="left"><br/></div> <div align="left"><font face="Arial" color="#7f7f7f"><span style="font-size:10pt">1. constructor() - the embedlet constructor</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">2. initialize() - get ready, configure hardware/JAPL</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">3. addListener() - wire them together (this is transparent to the embedlet...the container will   </span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">    do it on its behalf, so it's not a method call on the embedlet)</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">4. start() - do any startup stuff you need, including managing state or issuing initialization </span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">    events</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">5. stop() - shut down event generation</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">6. terminate() - clean up your mess</span></font></div> <div align="left"><br/> </div> <div align="left"><font face="Arial"><span style="font-size:10pt">Note that the addListener should be done by the Container, on the embedlets behalf, prior to the start() since if an embedlet posts an event during the start() method, it could end up generating an event (in an already started embedlet) that the original embedlet should receive (this is circular, but might be valid in some circumstances).  Either that or we ensure that no posted events are propagated till the start() method has completed (which might be tricky in a threaded environment or with synchronous events).</span></font></div> <div align="left"><br/> </div> <div align="left"><font face="Arial"><span style="font-size:10pt">However, this lifecycle should probably be a bit different from the Container's perspective!</span></font></div> <div align="left"><br/> </div> <div align="left"><font face="Arial"><span style="font-size:10pt">The container would perform steps 1 & 2 for all components, in dependency sequence.  So if your embedlet specified that it was dependent on others (eg. Threshold is dependent on Calibrator), then Calibrators would go through 1 & 2 before Threshold went through 1&2. This way, an embedlet knows that all it's dependencies have been initialized (but not started) when it's initialize() method is called (and it can thus check for existence, various context parameters, etc. of it's dependencies, if it needs/wants to).</span></font></div> <div align="left"><br/> </div> <div align="left"><font face="Arial"><span style="font-size:10pt">Then the container would do 3 & 4 in event consumer/producer order.  That is, it would start all event consumers before event producers for any particular event.  This makes sure that if a producer posts an event in it's start() method (event posting would be prohibited in the initialize() method) it is guaranteed that consumers are already listening.</span></font></div> <div align="left"><br/> </div> <div align="left"><font face="Arial"><span style="font-size:10pt">I think there will be value in having these two lifecycle sequences (from the containers perspective, one based on dependency and the other based on event consumer/producer ordering) as we dive into the container implementation.</span></font></div> <div align="left"><br/> </div> <div align="left"><font face="Arial"><span style="font-size:10pt">Does this make sense, or am I missing some fine points in your argument that I didn't read between the lines well enough?</span></font></div> <div align="left"><br/> </div> <div align="left"><br/> </div> <div align="left"><br/> </div> <div align="left"><br/></div> <div align="left"><br/></div> <div align="left"><br/> </div> <div align="left"><font face="Arial"><span style="font-size:10pt">...Andrzej</span></font></div> <div align="left"><br/> </div> <div align="left"><font face="Arial"><span style="font-size:10pt">Chaeron Corporation</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">http://www.chaeron.com</span></font></div> <div align="left"></div> </body> </html> |
|
From: Brill P. <bri...@ro...> - 2003-02-19 08:45:28
|
> The container should have a unique identity that could be concatenated with > the embedlet/JAPL id. Sure... though I wasn't trying to come up with an ID for embedlets and it needs to work without an embedlet system present. however that is certainly a workable solution. > Since the devices are likely to be at the end of a DNS, it would probably > make sense to structure the path as a URL: > > http://targetDevice.mycompany.com:port/containerID/EmbedletID/JAPLID > > or an inter-device (non tcp/ip) subset: > > /containerID/EmbedletID/JAPLID Yes, that's pretty much what I'd like to do... what I need to decide is how the id is generated etc, and who names the container? 1-Wire devices are easy, because they have their unique 8 byte serial numbers already, however I need some way to identify other types of peripherals... and the particular processor they are running on. Now if I could specify how everyone should implement their processors, I could use an internal serial number... but I can't, and this has to work with 3rd part devices, so the ID has to be in software (except for the 1-Wire devices). So, the id's can be auto generated during negotiation and start-up, or they can be named parameters in some sort of property set... for embedlets the named approach makes sense. I don't want to take everyone's attention away from the task at hand... just thought I send this out and let you all stew on it, and see what kind of ideas get generated. - Brill Pappin |
|
From: Christopher S. <cs...@oo...> - 2003-02-19 08:08:26
|
Field Programmable Gate Arrays They are actually quite powerful devices that can replace whole boards full of components. They now have micro-processor cores (up to 4x400 Mhz PowerPc'c per chip!) that you can drop in and integrate with your logic. There is a real parallel with what we are doing in that whole functional systems are defined in a 'C' based descriptive language with the possible aid of a graphical wiring tool. The advantage of this approach is that simulation is performed on the workstation by running the 'C' code. Then the verified part is generated (burned) from a blank or mass produced as a fabricated chip. http://www.xilinx.com/xlnx/xil_prodcat_landingpage.jsp?title=Virtex-II+Pro+F PGAs The cross over occurs when an embedlet configuration might get cross-compiled into a FPGA similar to what muvium is doing with the PIC core. I suspect that it won't be long before a Java VM is available as well that could leverage embedlets directly. James would probably have the most insight into this. James? > > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > _______________________________________________ > > I think they are traditionally used mainly for "glue" chip tasks, and can > replace a large number of discrete components quickly, and allow updating > via. software... similar to uC's but really for a different purpose > (although the lines seem to be blurring significantly). > > - Brill Pappin > Rogue Robotics > www.roguerobotics.com > > > ----- Original Message ----- > From: "Andrzej Jan Taramina" <an...@ch...> > To: <emb...@li...> > Sent: Tuesday, February 18, 2003 4:36 PM > Subject: [Embedlets-dev] [HW] HDL, FPGA and other assorted acronyms.... > > > > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > > _______________________________________________ > > > > Took me a while to figure out what FPGA meant. > > > > Anyway.....this seems to be very low level hardware oriented stuff. I > think that > > logica arrays (HDL, JHDL) is a great technology (reminds me of my youth > with > > digital logic decades ago) but way too low a level for our needs (though > it > > might make sense for device designers, who would then expose their > > hardware with a JAPL interface). Might be some good insights on > Graphical > > Widing techniques there. But I don't see much regarding our Embedlet > > Container implementation. > > > > > I think that putting Embedlets into an FPGA using this kind of > technology could > > > prove to be very interesting. > > > > Wouldn't you use FPGA to design/create/configure a processor that then > could > > run something like Java/Embedlets? In which case it just looks like > another > > processor (aJile, Intel, PIC, whatever) to us. Again, it seems > that FPGA > is > > much lower level (hardware design) than we are targeting. > > > > Unless I missed something. ;-) > > > > Andrzej Jan Taramina > > Chaeron Corporation: Enterprise System Solutions > > http://www.chaeron.com > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by:ThinkGeek > > Welcome to geek heaven. > > http://thinkgeek.com/sf > > _______________________________________________ > > Embedlets-developer mailing list > > Emb...@li... > > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. > The most comprehensive and flexible code editor you can use. > Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. > www.slickedit.com/sourceforge > _______________________________________________ > Embedlets-developer mailing list > Emb...@li... > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > |
|
From: Christopher S. <cs...@oo...> - 2003-02-19 07:28:23
|
The container should have a unique identity that could be concatenated with the embedlet/JAPL id. Since the devices are likely to be at the end of a DNS, it would probably make sense to structure the path as a URL: http://targetDevice.mycompany.com:port/containerID/EmbedletID/JAPLID or an inter-device (non tcp/ip) subset: /containerID/EmbedletID/JAPLID or an inter-embedlet address: /EmbedletId/JPLID > > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > _______________________________________________ > > I'd like to include a way to ID peripherals... not something strictly > required at this point beyond the instance for identification, but I have > dreams (possibly pipe) of being able to link multiple processors that all > see the same set of peripherals, regardless of what processor > they are on... > and use any transport to talk back and forth. > > Anyway, I'd like to put the skeleton into the library now, and > wanted ideas > on how systems could be identified. > > Really its based on context because not all processors have Ethernet ports > (or I'd just use the IP). I can be done at the local level with a name > something like "proc://spi0" or "proc://i2c1" or "proc://com2" etc... > however that doesn't work so well when there are multiple processors... > > It may be (read is) possible to auto-negotiate the ID of the processor > itself when it links with another processor, and that's the best solution > I've come up with so far... I wanted to pass it by you folks though for > ideas. > > - Brill Pappin > Rogue Robotics > www.roguerobotics.com > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. > The most comprehensive and flexible code editor you can use. > Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. > www.slickedit.com/sourceforge > _______________________________________________ > Embedlets-developer mailing list > Emb...@li... > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > |
|
From: Brill P. <bri...@ro...> - 2003-02-19 05:23:06
|
I'd like to include a way to ID peripherals... not something strictly required at this point beyond the instance for identification, but I have dreams (possibly pipe) of being able to link multiple processors that all see the same set of peripherals, regardless of what processor they are on... and use any transport to talk back and forth. Anyway, I'd like to put the skeleton into the library now, and wanted ideas on how systems could be identified. Really its based on context because not all processors have Ethernet ports (or I'd just use the IP). I can be done at the local level with a name something like "proc://spi0" or "proc://i2c1" or "proc://com2" etc... however that doesn't work so well when there are multiple processors... It may be (read is) possible to auto-negotiate the ID of the processor itself when it links with another processor, and that's the best solution I've come up with so far... I wanted to pass it by you folks though for ideas. - Brill Pappin Rogue Robotics www.roguerobotics.com |
|
From: Brill P. <bri...@ro...> - 2003-02-19 05:12:32
|
> How the Embedlet knows that the operation is complete can be handled in a > few different ways. The JAPL interface could expose a status method > (isDone() ) that the Embedlet could poll at it's convenience (note...this might > mean there are two timers going...a low level device implementation timer and > a higher level, more granular Embedlet polling timer). Nothing wrong with this > approach. I like that... and add it to the main peripheral interface. - Brill Pappin |
11 messages has been excluded from this view by a project administrator.
Thanks for helping keep SourceForge clean.
X