embedlets-developer Mailing List for Outpost Embedlet Container (Page 26)
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: Andrzej J. T. <an...@ch...> - 2003-02-11 19:06:26
|
For those that are using aJile-based processors (JStamp, SaJe and JStik's), aJile just released the software update version 3.16.09 for their developement tools and the static Runtime. You'll need to retain your Systronix-specific configs though. Since it's a bug fix release (the infamouse Threading bug that Charles found and I investigated is supposedly fixed!), I expect that the prior versions config files for Systronix boards will work fine. Oh...sorry 'bout the double post. Not sure what happened....might have been a network/mail problem, cause I didn't do it deliberately. Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Bruce B. <bb...@sy...> - 2003-02-11 07:46:16
|
The JSimm 6-slot backplane already supports multiple processors. Any signals of any slot can be isolated from the other slot(s). It can easily be split into two 3-slot planes. So two JStiks could talk via SPI or asynch serial or ?? Or into an ethernet switch. Wish I had time to play with this, or that someone else would carry the "parallel" torch. JStiks could also talk over the HSIO bus, but this would not easily be peer to peer. There is at least a partial Java implementation of Occam: http://www.wotug.org/occam/ http://www.cs.bris.ac.uk/~alan/javapp.html And I wish I had time to dig into CSP for Java. Bruce |
|
From: Jac K. <j.k...@th...> - 2003-02-11 07:13:43
|
On Tue, 11 Feb 2003, James Caska wrote: > When is JavaOne again? Early june...(10-13) -- Jac Kersing Technical Consultant The-Box Development j.k...@th... http://www.the-box.com |
|
From: James C. <ca...@vi...> - 2003-02-11 04:09:06
|
>And typical solutions based on disruptive technologies target lower margin and more >limited, emerging markets that are not profitable enough for the entrenched >companies to go after. Which is exactly why I actually would prefer, that given limited resources, we leave PLC's on the backburner and continue to focus on the wide-fan opportunity that triggered this group. I think this wide-fan opportunity has all the hallmarks of the sort of opportunity that disruptive technologies, and smaller more dynamic companies stand a real chance of beating out the establishment into. I already see it around me and am very keen for us as a group to 'close the loop' and demonstrate the data-hopping between the layers of the java stack that is emerging here by focusing as directly as possible on how data is pushed between the layers all the way back to the J2EE database from the internet fingers which may terminate at a JStamp/TINI/uVM device and ideally be able to plug these together to build at least a thin channel back to base. When is JavaOne again? James Caska http://www.muvium.com 'Java Bred for Embedded' > -----Original Message----- > From: emb...@li... > [mailto:emb...@li...]On Behalf Of > Andrzej Jan Taramina > Sent: Tuesday, February 11, 2003 2:46 PM > To: emb...@li... > Subject: [Embedlets-dev] Re: PLC's > > > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > _______________________________________________ > > James postulates: > > > Of course, the downside is well established PLC solutions doing > a darn fine, > > well tested and do the job. The question is what do we do that > they don't > > do already? that would be compelling enough to switch or suplement their > > solution space. > > Remember the Innovator's Dilema (I've finally gotten the book and > am part way > through it)? It points out that entrenched companies that are at > the top of the game, > and well managed are the ones that get creamed by disruptive > technology evolution. > > I think that Embedlets have the opportunity to be just such a > disruptive technology in > the embedded systems arena. > > And typical solutions based on disruptive technologies target > lower margin and more > limited, emerging markets that are not profitable enough for the > entrenched > companies to go after. That leads me to believe that this is > where you should look > for possible areas of application of Embedlets in the PLC > field.....low margin, > emerging market requirements. Not being an expert in PLC's I > don't know where > that might be...but it might cause you to rethink where to look at least. > > ...Andrzej > > Chaeron Corporation > http://www.chaeron.com > > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > Embedlets-developer mailing list > Emb...@li... > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > > |
|
From: Gregg G. W. <gr...@sk...> - 2003-02-11 04:06:47
|
>(Having been a system operator for over 5 years learned me the avarage >programmer is lazy and has not even the slightest idea what impact their >'design' will have in an operational environment.) :-) :-) :-) Many people on this list are engineers, not technicans! I appreciate your experience, just make sure you measure your response to similar stimulous in a way that allows everyone to see your concerns (this is something that I don't do well, because I get passionate about things that I have had bad experiences with too ;-). I spent 9 years working on and around telephone switching systems. I designed a language and the associated processes that controlled the duplex hardware (computer level, and device level) during the software retrofit process (replacing the software on a running switch). When something went wrong, I typically had 1 hour to go through 500,000 lines of base code (including assembly) to find problems (support calls at 3:00am in the morning). Sometimes I had 10 minutes to establish the extent of a problem by pouring through the status information and control display screens (at 300 baud) to establish what the next step was. As a matter of fact, I got to do this for the Prime Minister of the U.K. so that he could talk to his generals in Saudi-Arabia on the day the ground war started in 1990. Believe me when I say I am well aware of many issues that create headaches for persons managing systems. I won't say I know every issue that you know, but that's what's great about this list. We can utilize everyones expertise to make sure we make a really great decision about how to do all this stuff. visible security and encryption in the APIs: -1 pluggable comms interface that could provide security and connection authentication: +1 ----- gr...@cy... (Cyte Technologies Inc) |
|
From: Christopher S. <cs...@oo...> - 2003-02-11 03:58:05
|
> > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > _______________________________________________ > > >One of the related initiatives (see home page) is an XML format > for the PLC > >languages. This would be a natural gateway to convert PLC implementations > to > >Embedlets. > > Agreed,.. I think (despite others protests) that PLCs's are a terrifically > natural embedlet application. I have said before PLC ladder logic is > actually deceptively object orientated in its concept, are componentised > with well defined interfaces, have a large market and user base familiar > with using graphical tools to view their solutions, .. and are ONLY just > starting to standardise and their efforts to do so, as > encapsulated into an > XML document help us understand the problem domain and solutions > to problems > we haven't even yet thought about. > > I think PLC's are a rich field for embedlet's. Also could prove to be an > easy marketing target - demo to existing PLC manufacturers looking for a > competitive advantage. > > Of course, the downside is well established solutions doing a darn fine, > well tested and do the job. The question is what do we do that > they don't do > already? that would be compelling enough to switch or suplement their > solution space. 1. Enterprise integration 2. Inter-operable software components at all levels - removes proprietary barriers 3. Scalability 4. Customization via Java - you will be able to buy a 90% solution then add the 10% with a plugin Embedlet. > > James Caska > http://www.muvium.com > 'Java Bred for Embedded' > > > > > > > > > -----Original Message----- > > From: emb...@li... > > [mailto:emb...@li...]On Behalf Of > > Christopher Smith > > Sent: Tuesday, February 11, 2003 1:48 PM > > To: Embedlets-Developer > > Subject: [Embedlets-dev] Interesting related info > > > > > > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > > _______________________________________________ > > > > Topic tags:[MARKET] > > > > Here is an group providing standards and a forum for PLC > > manufacturers. This > > market, I feel, is a natural for integration with (and displacement by) > > embedded java, as I think James pointed out. There is a page on > the world > > wide market as of 1995 projected to 2000: > > > > http://www.plcopen.org/publication_press/wwmarket.htm > > > > One of the related initiatives (see home page) is an XML format > > for the PLC > > languages. This would be a natural gateway to convert PLC > > implementations to > > Embedlets. > > > > > > Christopher Smith > > OopScope > > 805-276-0598 > > > > > > > > > > ------------------------------------------------------- > > This SF.NET email is sponsored by: > > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > > http://www.vasoftware.com > > _______________________________________________ > > Embedlets-developer mailing list > > Emb...@li... > > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > > > > > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > Embedlets-developer mailing list > Emb...@li... > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > |
|
From: James C. <ca...@vi...> - 2003-02-11 03:54:00
|
>Get it to design a good Embedlet Container implementation? ;-) Good ol' Chicken and Egg Dilema' huh.. Perhaps a embedlet driven Neural Network Terminator might help us out by popping in from the future and show us how we did it.. or did we? Hmmm JC > -----Original Message----- > From: emb...@li... > [mailto:emb...@li...]On Behalf Of > Andrzej Jan Taramina > Sent: Tuesday, February 11, 2003 2:46 PM > To: emb...@li... > Subject: [Embedlets-dev] Re: Parallel processors > > > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > _______________________________________________ > > James ponders: > > > Then all we need to do is interconnect a couple hundred Xilinx on a > > board.. Hmmm, create a Java Hardware non-linear neural net function and > > hey presto - massively parallel hyper-performance java executing Neural > > Networks.. Now all I need to do is figure out what I would do with it. > > Get it to design a good Embedlet Container implementation? ;-) > > > ...Andrzej > > Chaeron Corporation > http://www.chaeron.com > > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > Embedlets-developer mailing list > Emb...@li... > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > > |
|
From: Andrzej J. T. <an...@ch...> - 2003-02-11 03:49:39
|
James ponders: > Then all we need to do is interconnect a couple hundred Xilinx on a > board.. Hmmm, create a Java Hardware non-linear neural net function and > hey presto - massively parallel hyper-performance java executing Neural > Networks.. Now all I need to do is figure out what I would do with it. Get it to design a good Embedlet Container implementation? ;-) ...Andrzej Chaeron Corporation http://www.chaeron.com |
|
From: Andrzej J. T. <an...@ch...> - 2003-02-11 03:45:44
|
Ted said: > Yes. And I very much appreciate the extra time you have taken in your > recent emails to lay all of these ideas out in meticulous detail. I have > not been exposed to a number of these ideas before and it is taking me > some time for me to digest them. I'm thrilled that my rather lengthy posts are seen as valuable! > I think that I am finally starting to see where you are going with the > Architecture and I must say is it blowing my mind. Wow...that's pretty high praise. Thanks, Ted. I came into this project with a bit of a "vision"....it's just taken me a while to refine it (with some excellent input from everyone here) and to get it "documented" to a point where someone else can start to understand it. >Your explanation of > how Servlets really were components was what punctured the paradigm bubble > I had been working under. After re-studying the ideas you have laid out > in your recent posts (like the various advantages of using context objects > over instance variables) I am starting to see that you have been working > at a whole abstraction level higher than I have been. Awesome.....I guess I'm not crazy after all! <grins> > I know that the posts that explained these ideas had to have been a PITA > to develop but perhaps you will be consoled by the fact that they are > going to provide an excellent base for the site documentation that we will > need to develop in order to explain this stuff to the rest of the world. Which is exactly why I have been taking the time to try to explain some of the concepts and my thinking in such depth. You've probably noticed that some of the posts are being edited and incorporated in the Architecture document too...that way they will be easily found by others that need to understand the architecture in the future, so the effort on email does pay off. > I must say that whatever effort I have put into helping out with this > project so far has already paid for itself many times over with just the > new knowledge I have gained. :-) And I appreciate the input everyone has been providing since it's helping to evolve the initial vision to something that might actually fly. Glad you have been gaining some value from the posts. Makes the sore typing fingers worth the effort and it's good to know that. Thanks for the kudos Ted. Much appreciated. Mind you, I just got a wireless card for my laptop, so I'm not typing this as I sit in front of the roaring fireplace (it's going down to -29C tonight here...brrrr!) in the living room instead of in my office. Very nice I must say.... ...Andrzej Chaeron Corporation http://www.chaeron.com |
|
From: Andrzej J. T. <an...@ch...> - 2003-02-11 03:45:19
|
James postulates: > Of course, the downside is well established PLC solutions doing a darn fine, > well tested and do the job. The question is what do we do that they don't > do already? that would be compelling enough to switch or suplement their > solution space. Remember the Innovator's Dilema (I've finally gotten the book and am part way through it)? It points out that entrenched companies that are at the top of the game, and well managed are the ones that get creamed by disruptive technology evolution. I think that Embedlets have the opportunity to be just such a disruptive technology in the embedded systems arena. And typical solutions based on disruptive technologies target lower margin and more limited, emerging markets that are not profitable enough for the entrenched companies to go after. That leads me to believe that this is where you should look for possible areas of application of Embedlets in the PLC field.....low margin, emerging market requirements. Not being an expert in PLC's I don't know where that might be...but it might cause you to rethink where to look at least. ...Andrzej Chaeron Corporation http://www.chaeron.com |
|
From: Ted K. <tk...@ya...> - 2003-02-11 03:40:35
|
Andrzej stated: > Thats the way I see it too. JAPL drivers are Embedlet Event producers. > Embedlets are Event consumers (though they can also produce events for > consumption further downstream). > > However, in order to keep the development of JAPL and Embedlets code > bases decoupled from each other, we might need to create a special "adapter" > that can take JAPL events and mangle them into Embedlet Events. After wresteling with this problem in the Elevator challenge for awhile I eventually arrived at the following: 1) Embedlets hold references to JAPL peripherals and are able to invoke methods on these peripherals in order to configure them, output data to them and also read data from them. 2) The events that JAPL peripherals generate are very simple 'interrupt' events with no further semantics embedded in them. This was done to minimize the JAPL peripheral event/Embedlet event impedanace matching work that needed to be done. 3) Embedlets would then treat JAPL interrupt events just like device drivers treat physical peripheral interrupts, by querying the device that generated the interrupt in order to determine what action needed to be taken. I do not know if this is the best solution or not but it seems to solve the problem reasonably well. Ted __________________________________________________ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.yahoo.com |
|
From: James C. <ca...@vi...> - 2003-02-11 03:26:07
|
>One of the related initiatives (see home page) is an XML format for the PLC >languages. This would be a natural gateway to convert PLC implementations to >Embedlets. Agreed,.. I think (despite others protests) that PLCs's are a terrifically natural embedlet application. I have said before PLC ladder logic is actually deceptively object orientated in its concept, are componentised with well defined interfaces, have a large market and user base familiar with using graphical tools to view their solutions, .. and are ONLY just starting to standardise and their efforts to do so, as encapsulated into an XML document help us understand the problem domain and solutions to problems we haven't even yet thought about. I think PLC's are a rich field for embedlet's. Also could prove to be an easy marketing target - demo to existing PLC manufacturers looking for a competitive advantage. Of course, the downside is well established solutions doing a darn fine, well tested and do the job. The question is what do we do that they don't do already? that would be compelling enough to switch or suplement their solution space. James Caska http://www.muvium.com 'Java Bred for Embedded' > -----Original Message----- > From: emb...@li... > [mailto:emb...@li...]On Behalf Of > Christopher Smith > Sent: Tuesday, February 11, 2003 1:48 PM > To: Embedlets-Developer > Subject: [Embedlets-dev] Interesting related info > > > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > _______________________________________________ > > Topic tags:[MARKET] > > Here is an group providing standards and a forum for PLC > manufacturers. This > market, I feel, is a natural for integration with (and displacement by) > embedded java, as I think James pointed out. There is a page on the world > wide market as of 1995 projected to 2000: > > http://www.plcopen.org/publication_press/wwmarket.htm > > One of the related initiatives (see home page) is an XML format > for the PLC > languages. This would be a natural gateway to convert PLC > implementations to > Embedlets. > > > Christopher Smith > OopScope > 805-276-0598 > > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > Embedlets-developer mailing list > Emb...@li... > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > > |
|
From: Ted K. <tk...@ya...> - 2003-02-11 03:20:48
|
Andrzej, >I think this approach is a good one. It allows serialization >where it makes sense (regardless of encoding technique: binary, >XML, code generated, something else), can be used to create a >generic Persistence service (in the long term sense). > >I think we've finally put this one to bed to everyone's satisfaction. Agreed? Yes. And I very much appreciate the extra time you have taken in your recent emails to lay all of these ideas out in meticulous detail. I have not been exposed to a number of these ideas before and it is taking me some time for me to digest them. I think that I am finally starting to see where you are going with the Architecture and I must say is it blowing my mind. Your explanation of how Servlets really were components was what punctured the paradigm bubble I had been working under. After re-studying the ideas you have laid out in your recent posts (like the various advantages of using context objects over instance variables) I am starting to see that you have been working at a whole abstraction level higher than I have been. I know that the posts that explained these ideas had to have been a PITA to develop but perhaps you will be consoled by the fact that they are going to provide an excellent base for the site documentation that we will need to develop in order to explain this stuff to the rest of the world. I must say that whatever effort I have put into helping out with this project so far has already paid for itself many times over with just the new knowledge I have gained. :-) Ted __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |
|
From: Christopher S. <cs...@oo...> - 2003-02-11 02:47:23
|
Topic tags:[MARKET] Here is an group providing standards and a forum for PLC manufacturers. This market, I feel, is a natural for integration with (and displacement by) embedded java, as I think James pointed out. There is a page on the world wide market as of 1995 projected to 2000: http://www.plcopen.org/publication_press/wwmarket.htm One of the related initiatives (see home page) is an XML format for the PLC languages. This would be a natural gateway to convert PLC implementations to Embedlets. Christopher Smith OopScope 805-276-0598 |
|
From: Christopher S. <cs...@oo...> - 2003-02-11 02:07:08
|
> Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > _______________________________________________ > Chess anyone? > Chris, > > >This is true. A possible application for embedlets is in multi-processor > >distributed computing where an array of JVM's each run a small set of > >identical embedlets to perform matrix operations. This would create a low > >power, low cost, high density super-computer with inherent near-neighbor > >communication. > > >Pretty exciting when you think about it! > > Ted and I have been discussing the concept of putting a couple of dozen > interconnected PIC core's on a XILINX FPGA and integrating the Xilinx Java > hardware realiser for static hardware functions coupled with > muvium running > on the PIC cores for the dynamic java management. > > Nice place to put parallel processing embedlets for some > seriously kick-ass > parallel processing java performance. > > Then all we need to do is interconnect a couple hundred Xilinx on > a board.. > Hmmm, create a Java Hardware non-linear neural net function and > hey presto - > massively parallel hyper-performance java executing Neural Networks.. Now > all I need to do is figure out what I would do with it. > > James Caska > http://www.muvium.com > 'Java Bred for Embedded' > > > > > > > -----Original Message----- > > From: emb...@li... > > [mailto:emb...@li...]On Behalf Of > > Christopher Smith > > Sent: Tuesday, February 11, 2003 11:57 AM > > To: emb...@li... > > Subject: RE: [Embedlets-dev] [Arch] Management of embedlets > > > > > > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > > _______________________________________________ > > > > > > > > > > > > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > > > _______________________________________________ > > > > > > > > > > IMO our embedlet architecture as it is now, is a little too > > much like a > > > > servlet architecture, and I don't think it fits the environment > > > as well as > > > > it should. > > > > I think it would be far better to do things the other way > > > around, so that > > > > the outpost device was sent its configuration, and then sent > > > its data back > > > > out to it's "listeners", similar to a subscriber pattern. This > > > would mean > > > > that the embedded devices could do their work in their own time > > > frame, as > > > > fast as they can reasonably do it, while not getting tied up > > servicing a > > > > single request. > > > > > > In the current architecture the 'real-time' components are JAPL > > > components. > > > In my imagining, JAPL components which are very much like, if > > not exactly > > > like, cork components will likely have Event driven > orientation. I think > > > embedlets are subscribers to JAPL components which have event > > > generators for > > > which Embedlets are listeners for sure. In this way all real-time > > > is handled > > > by the container and the real-time features of the platform. > > > > > > Again though, the embedlet implementation may use no JAPL > > > components at all! > > > It may simply be a logic configuration and not be a real-time system. > > > > > > > This is true. A possible application for embedlets is in multi-processor > > distributed computing where an array of JVM's each run a small set of > > identical embedlets to perform matrix operations. This would > create a low > > power, low cost, high density super-computer with inherent near-neighbor > > communication. > > > > Pretty exciting when you think about it! > > > > > James Caska > > > http://www.muvium.com > > > 'Java Bred for Embedded' > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: emb...@li... > > > > [mailto:emb...@li...]On Behalf Of > > > > Brill Pappin > > > > Sent: Tuesday, February 11, 2003 5:46 AM > > > > To: emb...@li... > > > > Subject: Re: [Embedlets-dev] [Arch] Management of embedlets > > > > > > > > > > > > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > > > > _______________________________________________ > > > > > > > > > > I'd narrow that down a little I think... for the most part > > > an Embedlet > > > > > > would be talking to/gathering data from a single device, so > > > maybe the > > > > > > embedlet should be a singleton... also helps reduce load on > > > > the embedded > > > > > > environment by not trying to do to much at once. > > > > > > > > > > I don't see any reason why we should limit an Embedlet to > > talk to one > > > > device, > > > > > arbitrarily. As for singletons...in a threaded system, you > > > > wouldn't even > > > > have > > > > > > > > I disagree with that, singeltons have their place in any > > > > development... most > > > > useful when you wnat to make sure an environment has only one > > > > instance copy > > > > regardless of how the implementation runs. I see it as good > > programming > > > > pratice to protect the areas of code that need it, against > > > poorly written > > > > implementations. > > > > IMO never depend on 3rd parties to do your work for you ;) > > > > > > > > > > For instance, on the physical level in Cork, only one > > device can be > > > > > > talking over I2C at any one time, so the underlying code > > > > allows the bus > > > > to > > > > > > be "locked" for any other requests, it also takes the > > > addresses of the > > > > > > available devices into account because you can't have more > > > > than one with > > > > > > the same address (in certain circumstances you can, but in > > > > that case it > > > > > > would be the same device as far as the software was concerned). > > > > > > > > > > Assuming it's a polled device, the Timer Service would create > > > a periodic > > > > event, > > > > > which an Embedlet would be listening for. The Container > > > would then call > > > > the > > > > > embedlet's event processing method with the timer event. > > The embedlet > > > > > > > would lock the bus, poll the device, unlock the bus, > > possibly do some > > > > other > > > > > processing (send a device-specific event based on the value > > > it got) and > > > > would > > > > > exit. > > > > > > > > I think you have to be careful here, as not all external > > devices return > > > > immediatly... for instance a 1-Wire net with a heavy wieght and > > > > radius could > > > > take several seconds to properly search, which is an eternatiy in > > > > electronics. I2C is much faster, but till may take several hunbred > > > > milliseconds depending on the device (the Devantech SRF08 will > > > > take from 70 > > > > to 100ms to return a single ping). > > > > > > > > > > Anyway, I don't think its really required that the embedlets > > > > behave that > > > > > > way, as the container can do the work of requesting data as > > > needed... > > > > > > however the embedlet should take into account that the > > container can > > > > only > > > > > > do things one at a time (for the most part). Anyway, quick, > > > > low traffic > > > > > > requests are important here. > > > > > > > > > > Not sure what you mean by this. The Container only manages > > > > Embedlets....it > > > > > would not be it's responsibility to talk to a JAPL/Cork interface. > > > > (Separation of > > > > > Concerns). The only time a physical device and Container would > > > > interact, > > > > > would be in the case of an interrupt drive device. When > > the interrupt > > > > came in > > > > > the JAPL code would use a static Container method to get a > > > handle to the > > > > > Event Service, so it could post an Embedlet Event into the queue. > > > > > > > > What I was thinking is that the container could to all the > > > talking in the > > > > background to lower level stuff, and make the data availible to > > > > the embedlet > > > > when it needed it... or the embedlet could request some > > > specific data from > > > > the underlaying code (or the container) and receive a callback > > > > whent he data > > > > was actually delivered. > > > > > > > > > > The other option of course is to dump the data elsewhere > > (into a DB > > > > maybe) > > > > > > and allow the embedlet to redirect requests, or be used only for > > > > outgoing > > > > > > transmission (and not service requests on its own). > > > > > > > > > > Not necessary (and DB's won't typically be available on > an embedded > > > > device). > > > > > The event queues effectively provide the capability you need (for > > > > transient > > > > > storage and linkage between a device, Embedlet and > > Container, but in a > > > > > decoupled manner). > > > > > > > > I agree, although I think it important that the device not have > > > to respond > > > > to the embedlet in the embedlets timeframe. so everything must > > > be loosely > > > > coupled so that the underlying system is not tied up trying to > > > service a > > > > single embedlet request, at the expense of all else it must do > > > for normal > > > > operation. > > > > > > > > IMO our embedlet architecture as it is now, is a little too > > much like a > > > > servlet architecture, and I don't think it fits the environment > > > as well as > > > > it should. > > > > I think it would be far better to do things the other way > > > around, so that > > > > the outpost device was sent its configuration, and then sent > > > its data back > > > > out to it's "listeners", similar to a subscriber pattern. This > > > would mean > > > > that the embedded devices could do their work in their own time > > > frame, as > > > > fast as they can reasonably do it, while not getting tied up > > servicing a > > > > single request. This is somewhat how I thought it was to > work, but I'm > > > > getting the idea recently that every request is polled from > > the outpost > > > > device... which will work up to a limited weight, but is a fairly > > > > significant point of failure as the outpost network grows > > (which is the > > > > problem we're attempting to solve here). > > > > > > > > - Brill Pappin > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > This SF.NET email is sponsored by: > > > > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > > > > http://www.vasoftware.com > > > > _______________________________________________ > > > > Embedlets-developer mailing list > > > > Emb...@li... > > > > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > This SF.NET email is sponsored by: > > > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > > > http://www.vasoftware.com > > > _______________________________________________ > > > Embedlets-developer mailing list > > > Emb...@li... > > > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > > > > > > > > > > ------------------------------------------------------- > > This SF.NET email is sponsored by: > > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > > http://www.vasoftware.com > > _______________________________________________ > > Embedlets-developer mailing list > > Emb...@li... > > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > > > > > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > Embedlets-developer mailing list > Emb...@li... > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > |
|
From: James C. <ca...@vi...> - 2003-02-11 01:31:08
|
Chris, >This is true. A possible application for embedlets is in multi-processor >distributed computing where an array of JVM's each run a small set of >identical embedlets to perform matrix operations. This would create a low >power, low cost, high density super-computer with inherent near-neighbor >communication. >Pretty exciting when you think about it! Ted and I have been discussing the concept of putting a couple of dozen interconnected PIC core's on a XILINX FPGA and integrating the Xilinx Java hardware realiser for static hardware functions coupled with muvium running on the PIC cores for the dynamic java management. Nice place to put parallel processing embedlets for some seriously kick-ass parallel processing java performance. Then all we need to do is interconnect a couple hundred Xilinx on a board.. Hmmm, create a Java Hardware non-linear neural net function and hey presto - massively parallel hyper-performance java executing Neural Networks.. Now all I need to do is figure out what I would do with it. James Caska http://www.muvium.com 'Java Bred for Embedded' > -----Original Message----- > From: emb...@li... > [mailto:emb...@li...]On Behalf Of > Christopher Smith > Sent: Tuesday, February 11, 2003 11:57 AM > To: emb...@li... > Subject: RE: [Embedlets-dev] [Arch] Management of embedlets > > > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > _______________________________________________ > > > > > > > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > > _______________________________________________ > > > > > > > IMO our embedlet architecture as it is now, is a little too > much like a > > > servlet architecture, and I don't think it fits the environment > > as well as > > > it should. > > > I think it would be far better to do things the other way > > around, so that > > > the outpost device was sent its configuration, and then sent > > its data back > > > out to it's "listeners", similar to a subscriber pattern. This > > would mean > > > that the embedded devices could do their work in their own time > > frame, as > > > fast as they can reasonably do it, while not getting tied up > servicing a > > > single request. > > > > In the current architecture the 'real-time' components are JAPL > > components. > > In my imagining, JAPL components which are very much like, if > not exactly > > like, cork components will likely have Event driven orientation. I think > > embedlets are subscribers to JAPL components which have event > > generators for > > which Embedlets are listeners for sure. In this way all real-time > > is handled > > by the container and the real-time features of the platform. > > > > Again though, the embedlet implementation may use no JAPL > > components at all! > > It may simply be a logic configuration and not be a real-time system. > > > > This is true. A possible application for embedlets is in multi-processor > distributed computing where an array of JVM's each run a small set of > identical embedlets to perform matrix operations. This would create a low > power, low cost, high density super-computer with inherent near-neighbor > communication. > > Pretty exciting when you think about it! > > > James Caska > > http://www.muvium.com > > 'Java Bred for Embedded' > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > From: emb...@li... > > > [mailto:emb...@li...]On Behalf Of > > > Brill Pappin > > > Sent: Tuesday, February 11, 2003 5:46 AM > > > To: emb...@li... > > > Subject: Re: [Embedlets-dev] [Arch] Management of embedlets > > > > > > > > > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > > > _______________________________________________ > > > > > > > > I'd narrow that down a little I think... for the most part > > an Embedlet > > > > > would be talking to/gathering data from a single device, so > > maybe the > > > > > embedlet should be a singleton... also helps reduce load on > > > the embedded > > > > > environment by not trying to do to much at once. > > > > > > > > I don't see any reason why we should limit an Embedlet to > talk to one > > > device, > > > > arbitrarily. As for singletons...in a threaded system, you > > > wouldn't even > > > have > > > > > > I disagree with that, singeltons have their place in any > > > development... most > > > useful when you wnat to make sure an environment has only one > > > instance copy > > > regardless of how the implementation runs. I see it as good > programming > > > pratice to protect the areas of code that need it, against > > poorly written > > > implementations. > > > IMO never depend on 3rd parties to do your work for you ;) > > > > > > > > For instance, on the physical level in Cork, only one > device can be > > > > > talking over I2C at any one time, so the underlying code > > > allows the bus > > > to > > > > > be "locked" for any other requests, it also takes the > > addresses of the > > > > > available devices into account because you can't have more > > > than one with > > > > > the same address (in certain circumstances you can, but in > > > that case it > > > > > would be the same device as far as the software was concerned). > > > > > > > > Assuming it's a polled device, the Timer Service would create > > a periodic > > > event, > > > > which an Embedlet would be listening for. The Container > > would then call > > > the > > > > embedlet's event processing method with the timer event. > The embedlet > > > > > would lock the bus, poll the device, unlock the bus, > possibly do some > > > other > > > > processing (send a device-specific event based on the value > > it got) and > > > would > > > > exit. > > > > > > I think you have to be careful here, as not all external > devices return > > > immediatly... for instance a 1-Wire net with a heavy wieght and > > > radius could > > > take several seconds to properly search, which is an eternatiy in > > > electronics. I2C is much faster, but till may take several hunbred > > > milliseconds depending on the device (the Devantech SRF08 will > > > take from 70 > > > to 100ms to return a single ping). > > > > > > > > Anyway, I don't think its really required that the embedlets > > > behave that > > > > > way, as the container can do the work of requesting data as > > needed... > > > > > however the embedlet should take into account that the > container can > > > only > > > > > do things one at a time (for the most part). Anyway, quick, > > > low traffic > > > > > requests are important here. > > > > > > > > Not sure what you mean by this. The Container only manages > > > Embedlets....it > > > > would not be it's responsibility to talk to a JAPL/Cork interface. > > > (Separation of > > > > Concerns). The only time a physical device and Container would > > > interact, > > > > would be in the case of an interrupt drive device. When > the interrupt > > > came in > > > > the JAPL code would use a static Container method to get a > > handle to the > > > > Event Service, so it could post an Embedlet Event into the queue. > > > > > > What I was thinking is that the container could to all the > > talking in the > > > background to lower level stuff, and make the data availible to > > > the embedlet > > > when it needed it... or the embedlet could request some > > specific data from > > > the underlaying code (or the container) and receive a callback > > > whent he data > > > was actually delivered. > > > > > > > > The other option of course is to dump the data elsewhere > (into a DB > > > maybe) > > > > > and allow the embedlet to redirect requests, or be used only for > > > outgoing > > > > > transmission (and not service requests on its own). > > > > > > > > Not necessary (and DB's won't typically be available on an embedded > > > device). > > > > The event queues effectively provide the capability you need (for > > > transient > > > > storage and linkage between a device, Embedlet and > Container, but in a > > > > decoupled manner). > > > > > > I agree, although I think it important that the device not have > > to respond > > > to the embedlet in the embedlets timeframe. so everything must > > be loosely > > > coupled so that the underlying system is not tied up trying to > > service a > > > single embedlet request, at the expense of all else it must do > > for normal > > > operation. > > > > > > IMO our embedlet architecture as it is now, is a little too > much like a > > > servlet architecture, and I don't think it fits the environment > > as well as > > > it should. > > > I think it would be far better to do things the other way > > around, so that > > > the outpost device was sent its configuration, and then sent > > its data back > > > out to it's "listeners", similar to a subscriber pattern. This > > would mean > > > that the embedded devices could do their work in their own time > > frame, as > > > fast as they can reasonably do it, while not getting tied up > servicing a > > > single request. This is somewhat how I thought it was to work, but I'm > > > getting the idea recently that every request is polled from > the outpost > > > device... which will work up to a limited weight, but is a fairly > > > significant point of failure as the outpost network grows > (which is the > > > problem we're attempting to solve here). > > > > > > - Brill Pappin > > > > > > > > > > > > ------------------------------------------------------- > > > This SF.NET email is sponsored by: > > > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > > > http://www.vasoftware.com > > > _______________________________________________ > > > Embedlets-developer mailing list > > > Emb...@li... > > > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > > > > > > > > > > > > > > ------------------------------------------------------- > > This SF.NET email is sponsored by: > > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > > http://www.vasoftware.com > > _______________________________________________ > > Embedlets-developer mailing list > > Emb...@li... > > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > Embedlets-developer mailing list > Emb...@li... > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > > |
|
From: Christopher S. <cs...@oo...> - 2003-02-11 00:56:29
|
> > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > _______________________________________________ > > > > IMO our embedlet architecture as it is now, is a little too much like a > > servlet architecture, and I don't think it fits the environment > as well as > > it should. > > I think it would be far better to do things the other way > around, so that > > the outpost device was sent its configuration, and then sent > its data back > > out to it's "listeners", similar to a subscriber pattern. This > would mean > > that the embedded devices could do their work in their own time > frame, as > > fast as they can reasonably do it, while not getting tied up servicing a > > single request. > > In the current architecture the 'real-time' components are JAPL > components. > In my imagining, JAPL components which are very much like, if not exactly > like, cork components will likely have Event driven orientation. I think > embedlets are subscribers to JAPL components which have event > generators for > which Embedlets are listeners for sure. In this way all real-time > is handled > by the container and the real-time features of the platform. > > Again though, the embedlet implementation may use no JAPL > components at all! > It may simply be a logic configuration and not be a real-time system. > This is true. A possible application for embedlets is in multi-processor distributed computing where an array of JVM's each run a small set of identical embedlets to perform matrix operations. This would create a low power, low cost, high density super-computer with inherent near-neighbor communication. Pretty exciting when you think about it! > James Caska > http://www.muvium.com > 'Java Bred for Embedded' > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > From: emb...@li... > > [mailto:emb...@li...]On Behalf Of > > Brill Pappin > > Sent: Tuesday, February 11, 2003 5:46 AM > > To: emb...@li... > > Subject: Re: [Embedlets-dev] [Arch] Management of embedlets > > > > > > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > > _______________________________________________ > > > > > > I'd narrow that down a little I think... for the most part > an Embedlet > > > > would be talking to/gathering data from a single device, so > maybe the > > > > embedlet should be a singleton... also helps reduce load on > > the embedded > > > > environment by not trying to do to much at once. > > > > > > I don't see any reason why we should limit an Embedlet to talk to one > > device, > > > arbitrarily. As for singletons...in a threaded system, you > > wouldn't even > > have > > > > I disagree with that, singeltons have their place in any > > development... most > > useful when you wnat to make sure an environment has only one > > instance copy > > regardless of how the implementation runs. I see it as good programming > > pratice to protect the areas of code that need it, against > poorly written > > implementations. > > IMO never depend on 3rd parties to do your work for you ;) > > > > > > For instance, on the physical level in Cork, only one device can be > > > > talking over I2C at any one time, so the underlying code > > allows the bus > > to > > > > be "locked" for any other requests, it also takes the > addresses of the > > > > available devices into account because you can't have more > > than one with > > > > the same address (in certain circumstances you can, but in > > that case it > > > > would be the same device as far as the software was concerned). > > > > > > Assuming it's a polled device, the Timer Service would create > a periodic > > event, > > > which an Embedlet would be listening for. The Container > would then call > > the > > > embedlet's event processing method with the timer event. The embedlet > > > would lock the bus, poll the device, unlock the bus, possibly do some > > other > > > processing (send a device-specific event based on the value > it got) and > > would > > > exit. > > > > I think you have to be careful here, as not all external devices return > > immediatly... for instance a 1-Wire net with a heavy wieght and > > radius could > > take several seconds to properly search, which is an eternatiy in > > electronics. I2C is much faster, but till may take several hunbred > > milliseconds depending on the device (the Devantech SRF08 will > > take from 70 > > to 100ms to return a single ping). > > > > > > Anyway, I don't think its really required that the embedlets > > behave that > > > > way, as the container can do the work of requesting data as > needed... > > > > however the embedlet should take into account that the container can > > only > > > > do things one at a time (for the most part). Anyway, quick, > > low traffic > > > > requests are important here. > > > > > > Not sure what you mean by this. The Container only manages > > Embedlets....it > > > would not be it's responsibility to talk to a JAPL/Cork interface. > > (Separation of > > > Concerns). The only time a physical device and Container would > > interact, > > > would be in the case of an interrupt drive device. When the interrupt > > came in > > > the JAPL code would use a static Container method to get a > handle to the > > > Event Service, so it could post an Embedlet Event into the queue. > > > > What I was thinking is that the container could to all the > talking in the > > background to lower level stuff, and make the data availible to > > the embedlet > > when it needed it... or the embedlet could request some > specific data from > > the underlaying code (or the container) and receive a callback > > whent he data > > was actually delivered. > > > > > > The other option of course is to dump the data elsewhere (into a DB > > maybe) > > > > and allow the embedlet to redirect requests, or be used only for > > outgoing > > > > transmission (and not service requests on its own). > > > > > > Not necessary (and DB's won't typically be available on an embedded > > device). > > > The event queues effectively provide the capability you need (for > > transient > > > storage and linkage between a device, Embedlet and Container, but in a > > > decoupled manner). > > > > I agree, although I think it important that the device not have > to respond > > to the embedlet in the embedlets timeframe. so everything must > be loosely > > coupled so that the underlying system is not tied up trying to > service a > > single embedlet request, at the expense of all else it must do > for normal > > operation. > > > > IMO our embedlet architecture as it is now, is a little too much like a > > servlet architecture, and I don't think it fits the environment > as well as > > it should. > > I think it would be far better to do things the other way > around, so that > > the outpost device was sent its configuration, and then sent > its data back > > out to it's "listeners", similar to a subscriber pattern. This > would mean > > that the embedded devices could do their work in their own time > frame, as > > fast as they can reasonably do it, while not getting tied up servicing a > > single request. This is somewhat how I thought it was to work, but I'm > > getting the idea recently that every request is polled from the outpost > > device... which will work up to a limited weight, but is a fairly > > significant point of failure as the outpost network grows (which is the > > problem we're attempting to solve here). > > > > - Brill Pappin > > > > > > > > ------------------------------------------------------- > > This SF.NET email is sponsored by: > > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > > http://www.vasoftware.com > > _______________________________________________ > > Embedlets-developer mailing list > > Emb...@li... > > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > > > > > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > Embedlets-developer mailing list > Emb...@li... > https://lists.sourceforge.net/lists/listinfo/embedlets-developer |
|
From: James C. <ca...@vi...> - 2003-02-11 00:06:56
|
>I think we've finally put this one to bed to everyone's satisfaction. Agreed? +1 JC > -----Original Message----- > From: emb...@li... > [mailto:emb...@li...]On Behalf Of > Andrzej Jan Taramina > Sent: Tuesday, February 11, 2003 10:52 AM > To: emb...@li... > Subject: [Embedlets-dev] [Arch] Properties and such > > > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > _______________________________________________ > > Chris suggests: > > > 1. The Properties service reads the input media (eg. XML) and > encounters an > > object. > > 2. The Properties service instantiates the object based on the 'class' > > attribute on the stream. The objects' Class is assumed to be > preloaded in > > the installation, thus avoiding byte code streaming. > > 3. The object implements the PropertyAccess interface (orginally called > > Persistent), which defines the readProperties(Properties p) method. > > 4. The component reads its properties using getProperty(String > Name) methods > > of the Properties object. Components can access other objects > by reference > > using getObjectProperty(objectName). > > 5. The container manages the life cycle processes by informing each > > component of its current state: create (implied in > constructor), initialize, > > start, stop, terminate. > > Yup....I agree. And it's even easier if the objects being > reconstituted are > Context objects, rather than an Embedlet itself, separating the > data-oriented > from the process-oriented in a clean way. > > I think this approach is a good one. It allows serialization > where it makes > sense (regardless of encoding technique: binary, XML, code generated, > something else), can be used to create a generic Persistence > service (in the > long term sense). > > I think we've finally put this one to bed to everyone's > satisfaction. Agreed? > > > Andrzej Jan Taramina > Chaeron Corporation: Enterprise System Solutions > http://www.chaeron.com > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > Embedlets-developer mailing list > Emb...@li... > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > > |
|
From: Andrzej J. T. <an...@ch...> - 2003-02-10 23:58:44
|
James clarifies: > In the current architecture the 'real-time' components are JAPL > components. In my imagining, JAPL components which are very much like, if > not exactly like, cork components will likely have Event driven > orientation. I think embedlets are subscribers to JAPL components which > have event generators for which Embedlets are listeners for sure. In this > way all real-time is handled by the container and the real-time features > of the platform. Thats the way I see it too. JAPL drivers are Embedlet Event producers. Embedlets are Event consumers (though they can also produce events for consumption further downstream). However, in order to keep the development of JAPL and Embedlets code bases decoupled from each other, we might need to create a special "adapter" that can take JAPL events and mangle them into Embedlet Events. > Step1: Get Underwear > Step2: .. > Step3: Profits Hey...cheesie poofs are WAY more important than underwear! Get your priorities straight man! ;-) Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Andrzej J. T. <an...@ch...> - 2003-02-10 23:54:25
|
Chris said: > I think that everyone agrees that: > > 1. The classic binary serialization is not going to work. (It is not > supported on all platforms, version issues etc.) > 2. XML should form the basis for defining Embedlet configuration > 3. Life cycle and configuration are separate issues that require separate > consideration. > 4. Dynamic configuration is a good thing. > 5. Static configuration may be required on constrained platforms (James is > the expert on this one). I agree. Only one minor clarification. #4 is a Good Thing(tm) but it should be an optional service (not a mandatory part of the core). > The issue is: > > 1. Whether to do static or dynamic configuration first. I think there are some other steps (as Chris notes) that make sense to do first, before we have to make this decision. > My feeling at this point in order to move ahead is that we should : > > 1. Lay down the Embedlet interface that defines the base requirements: > identification, life cycle... > 2. Code the SimpleEmbedlet base implementation. > 3. Define the configuration XML schema for the SimpleEmbedlet. > 4 Branch off the dynamic and static camps to work in parallel to achieve > both objectives, while coordinating efforts where the specifications > overlap. > 5. Show up at JavaOne with running demo(s). (I skipped a couple of steps!) Again, I definitely am on board with this. (fixed the numbering from Chris' post though. Hey....you need a Counting Service Chris? ;-) ). For #3....we don't need a formal schema or dtd right off the bat. Best to design the config format by example (since it's liable to evolve fast during development) and then when it stabilizes, reverse engineer a more formal schema/dtd from it. For #4, the classes and methods to do a lot of the config stuff can be made easily common between the two camps. So providing we try to leverage the common code (no point in reinventing the wheel) that sounds like a good plan. I don't think step 4 will be dynamic versus static as much as two different platform implementations (eg. TStik vs uVM, where one happens to support dynamic and the other not). So there may be other implementation differences besides just dynamic vs static. When it comes to #5....Yeah Baby! (in my best Shagadelic voice of course). ;-) Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Andrzej J. T. <an...@ch...> - 2003-02-10 23:54:19
|
Nicolo replies: > Which is exactly the point. You don't need kXML or any parser. Actually > you don't parse, because it's *already* parsed. So you "parse" it and send > the "predigested" stuff to the device. Yeah...but if we are doing SOAP stuff (Management Service) then we'll probably have something like kXML kicking around anyway. Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Andrzej J. T. <an...@ch...> - 2003-02-10 23:54:16
|
Chris suggests: > 1. The Properties service reads the input media (eg. XML) and encounters an > object. > 2. The Properties service instantiates the object based on the 'class' > attribute on the stream. The objects' Class is assumed to be preloaded in > the installation, thus avoiding byte code streaming. > 3. The object implements the PropertyAccess interface (orginally called > Persistent), which defines the readProperties(Properties p) method. > 4. The component reads its properties using getProperty(String Name) methods > of the Properties object. Components can access other objects by reference > using getObjectProperty(objectName). > 5. The container manages the life cycle processes by informing each > component of its current state: create (implied in constructor), initialize, > start, stop, terminate. Yup....I agree. And it's even easier if the objects being reconstituted are Context objects, rather than an Embedlet itself, separating the data-oriented from the process-oriented in a clean way. I think this approach is a good one. It allows serialization where it makes sense (regardless of encoding technique: binary, XML, code generated, something else), can be used to create a generic Persistence service (in the long term sense). I think we've finally put this one to bed to everyone's satisfaction. Agreed? Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: James C. <ca...@vi...> - 2003-02-10 23:41:40
|
>As a result of some of the above insights, I am changing my vote on >serialization as an appropriate initialization approach to: -0 (for now). -0 (for now)... Ohhh you mean you will be changing it to +1 or perhaps +666 shortly then ;-) JC > -----Original Message----- > From: emb...@li... > [mailto:emb...@li...]On Behalf Of > Andrzej Jan Taramina > Sent: Tuesday, February 11, 2003 4:20 AM > To: emb...@li... > Subject: [Embedlets-dev] [Impl] Initialization process: Code Gen vs. > Serialization > > > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > _______________________________________________ > > James provides some insights > > > Can you clear up a few points for me. I have been reading your > changes to > > your doc, good work BTW, about the Build Process. > > Thanks...it was just a reformat of some of my earlier posts. > I'll probably add a > similar appendix to document our Initialization strategy > discussion (eg. code > gen vs serialization and such) sometime this week. > > > So, in summary we take the XML Embedlet Configuration (Or wiring model) > > and autogenerate the code to build the embedlet application this is > > 'included' in the build and called by the container to construct the > > application, ie Instantiate the Embedlet tree from the XML into a > > initialisation code. Ie Create a verbose code version of > serialisation? - > > pseudo Serialisation. > > Exactly. > > > So now I see your advatages > > - platforms that don't support serialisation can still deploy > the Embedlet > > applications. - Versioning is not a problem > > Yup.....plus smaller memory footprint and less startup processing > time which > might be very valuable on small platforms. > > > However, Now that I work through it I DEFINETELY! think these should be > > interchangeable with platforms that do support serialisation because the > > hardcoded serialisation could be a very substantial chunk of code > > actually. If this can be done 'off device' where the Serialisation API > > transforms the XML Embedlet application into a binary on behalf of the > > target device then this is definetely more lightweight for the device as > > it doesn't need all this config code. The config code will most > certainly > > take up more FLASH than to store the serialisation stream for example. > > Not if the serialization stream is in XML format! Bytecodes are > pretty compact > compared to that. Also, code to do the deserialization is pretty > substantial, so > you would need a LOT of init code before it exceeded that needed for > deserialization. > > And lets consider low-level code reuse. If the container > implementation is > going to provide dynamic reconfig ability, it will need to be > able to create and > intialize config/context objects, and thus would have the > initialization code > anyway. It should be possible to separate this code into > reuseable methods, > so that it can be reused for both a static startup scenario, and > for dynamic > reconfigs. Less coding...smaller footprint too. > > > What I would like here is to 'unify' these two concepts because they are > > the same thing, > > At some conceptual level, you are correct...they are the same thing. > > > - Pseudo Serialisation ie Build Process Bytecode that implementation > > serialisation ie Traverses and builds the Embedlet object heirachy > > directly in code - Serialisation API which 'understands' the target and > > generates the object heirachy directly > > > > The end result of both these processes is the internal binary > > representation of the Embedlet application generated from the XML > > schematic representation which may have been generated from the Wiring > > Application. > > Yup. > > > Lets see if we can use them interchangeably pending device capabilities, > > in fact lets see if we can't use one to make it easy to create > the other. > > Actually, James, I want to ensure that the Embedlet Spec does not > preclude > you from using one implementation or the other or even some other > technique > altogether. This is a container implementation detail that should be > transparent to the developer of Embedlets. It is only visible during the > deployment process itself, not during development and not during > the runtime > (from an Embedlets perspective....it shouldn't know nor care > about how it's > context objects were created, so long as it gets one!). > > > What might it look like... during the build process > > > > 1) We start with the XML Embedlet description of the application > > 2) The build process generates a configuration ByteCode script, > our pseudo > > serialisation script > > 3) Create a Virtual Container ie Our PC Container, > > and execute the pseudo serialisation script to instantiate the object > > heirachy in our PC Container > > 4) The correctness of the Embdlet > > configuration is verified by the virtual container > > > > Now this is where the process diverges. > > > > EITHER the Target has no serialisation API > > > > 5) The pseudo serialisation code is inserted into the Container startup > > constructor > > > > OR the Platform has a serialisation API > > > > ** The developer (Vendor) of the Serialisation API then uses > introspection > > or system serialisation (on the full blown VM) to generate a serialised > > version of the PC Virtual Container contents compatible with > their target > > platform. > > 5) The serialised version of the bytecode startup constructor is > > inserted into the Container startup constructor > > > > 6) The static image is built and targeted for the appropriate platform. > > > > > > In this way we get the best of both worlds > > I agree....like I said, it's an internal container implementation > detail (supported > by the build/deployment process), that should not be precluded by > the Spec. > That is very doable. > > In fact, it's even easier if Embedlets never use instance > variables (good for > threading too, just like Servlets)...but instead store all their > properties in > externally maintained context objects (with both Container and > Component/Embedlet scope...though we might want a very lightweight Event > scoped context capability as well). Since these context objects > are really just > JavaBeans value holders (minus any JavaBeans event stuff), > initialization of > these objects and Embedlet lifecycle become decoupled, thus making the > choice of initialization technique (code gen, serialization or > something else) a > non-issue. > > Ah! My architectural concept turns out to enable the > serialization proponents > to have their cake and eat it too. Awesome! <grins> > > > and the also if we provide a > > standard reference implementation for the way the Serialisation API > > interacts with Container to serialise the application then it will help > > other VM vendors with their efforts. > > Since it's a low level container implementation issue, I think > there is no reason > for us to create a standard serialization API. Each Outpost > implementation > vendor/platform would probably want to do it differently anyhow. > > > In this way > > 1) We keep the XML Embedlet Description > > 2) We keep the build process to autogenerate the configuration code > > 3) We keep the ability to support non serialise support VM's > > 4) We add the ability to support serialise enabled VM's > > 5) We add the ability to strip the configuration code out of > the VM making > > it more lightweight > > 6) We add the ability to upload new configurations > > dynamically into the container (if they only use the same classes) > > Yup.....but let's be clear....the spec should allow for such > variations in the > implementation of a container. It should not mandate that you > use any specific > approach. > > I'll give some thought to this and ensure that any potential spec > does not limit > the container implementation abilities, thus ensuring the most amount of > flexibility. > > Where the actual implementation of initialization makes a > difference is with > Ted's Live Wiring tool, since both the Graphical tool and > Container that it uses > would have to use the same approach. But since we've deferred > work on the > live wiring tool till a bit later in the process, this is not at > issue right now. > > As a result of some of the above insights, I am changing my vote on > serialization as an appropriate initialization approach to: -0 (for now). > > > > > > Andrzej Jan Taramina > Chaeron Corporation: Enterprise System Solutions > http://www.chaeron.com > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > Embedlets-developer mailing list > Emb...@li... > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > > |
|
From: James C. <ca...@vi...> - 2003-02-10 23:39:34
|
>4. Show up at JavaOne with running demo(s). (I skipped a couple of steps!) Step1: Get Underwear Step2: .. Step3: Profits Any Southpark fans out there! - Couldn't resist :-) JC > -----Original Message----- > From: emb...@li... > [mailto:emb...@li...]On Behalf Of > Christopher Smith > Sent: Tuesday, February 11, 2003 8:03 AM > To: emb...@li... > Subject: RE: [Embedlets-dev] Re: Serialization... > > > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > _______________________________________________ > > > I think that everyone agrees that: > > 1. The classic binary serialization is not going to work. (It is not > supported on all platforms, version issues etc.) > 2. XML should form the basis for defining Embedlet configuration > 3. Life cycle and configuration are separate issues that require separate > consideration. > 4. Dynamic configuration is a good thing. > 5. Static configuration may be required on constrained platforms > (James is > the expert on this one). > > The issue is: > > 1. Whether to do static or dynamic configuration first. > > My feeling at this point in order to move ahead is that we should : > > 1. Lay down the Embedlet interface that defines the base requirements: > identification, life cycle... > 2. Code the SimpleEmbedlet base implementation. > 2. Define the configuration XML schema for the SimpleEmbedlet. > 3. Branch off the dynamic and static camps to work in parallel to achieve > both objectives, while coordinating efforts where the specifications > overlap. > 4. Show up at JavaOne with running demo(s). (I skipped a couple of steps!) > > > > > > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > > _______________________________________________ > > > > Ted: > > > > > The same way that serialized objects that have references to > > > non-serializeable objects like Threads are properly de-serialized, by > > > using custom serialization. > > > With custom serialization the developer gets to define > whatever code is > > > necessary to properly reconstitute the object when it is > > deserialized. If > > > it is a JAPL object that is getting deserialized then the hardware is > > > called with the proper initialization parameters in the custom > > > deserialization code. > > > > > Again, custom serialization can make sure that all of the > > things that are > > > not serializeable during 'freeze' time, like live communications > > > connections and Threads, can all be reconnected at 'thaw' time. > > > > I have worked with serialization extensively, Ted....and so am > > fully aware of > > the need for custom code to do this kind of things. I built a > > huge Resource > > Planning System (many years ago) that used serialization as it's > > persistence > > layer (more for prototyping convenience than anything else....we > > were going to > > map the persistence to a DBMS at some point and replace the > serialization > > approach), and have first hand experience with the issues you can > > run into. > > > > It just gets very complicated and ugly really fast when you have > > to tie this into > > a container-controlled lifecycle process. You may not be able to > > reconstitute a > > connection (for example) at the time you are deserializing....the > > dependencies > > coupled with the temporal issues become a bear to deal with. One > > solution to > > this complexity is to have the deserializer just include dummy > > entries for non- > > serializable objects during the thaw, and then have the > lifecycle service > > initialize and set those values later. > > > > However, I would propose the best way to handle this is as per > my earlier > > email, where the context objects (which contain all the config > > info that the > > container or embedlet needs) be serialized and not the embedlet itself > > (meaning instance variables). A context object would not have > > any references > > (from a startup perspective) to non-serializeable objects so > > reconstituting it is > > much easier...no custom serialization code required. All such > > context objects > > can be thawed in one fell swoop, ignoring init/lifecycle > > requirements, cause > > there wouldn't be any. Then during the initialization process > > (controlled by the > > contaienr lifecycle service) the Embedlet is given it's context > > objects, and then > > can initialize things like connections, JAPL devices, etc. (and > > very likely store > > references to these dynamic resources using the generic > > properties capability > > in the context object). > > > > Doing this allows the flexibility to decouple configuration > > encoding (code gen, > > serialization, etc.) from lifecycle intialization, and thus > > making it a container > > implementation choice that is transparent to the embedlet. > > > > Cake and eat it too, Ted. You can have your serialization....and > > I can have a > > clean lifecycle implementation. > > > > > With a serialized application, the components, JAPL > > peripherals, services, etc. > > > have already all been put into the 'running' lifecycle state > > (or other desired > > > states) and all of their configurations have already been set using an > > > inspector or perhaps an easier to use customizer. Most of the > > complexity has > > > already been handled by the application assembler in a PnP > > instant feedback > > > environment. > > > > Sure...if you are using the Live Wiring tool and a container that > > was custom > > crafted to support that. But think about this, itdoesn't work > > when you are > > deploying to a real device. Sure....you've serialized the whole object > > graph....then you download it to the real controller (say a > > TStik). Connections > > are NOT active at this point.....JAPL devices are NOT > > initialized....so you still > > have to go through the lifecycle process to initialize > > everything. And a serialize > > object graph does not give you any clues as to what sequence you > > need to do > > this in (eg. dependencies). So you still need a lot of the > > config info that tells > > you how and in what sequence to do this initialization and have > > to run through > > a complete lifecycle, container startup process, thus negating a > > lot of the > > benefits of the serialized approach. > > > > Now before you start fretting about this....go back up and read > > my thoughts on > > decoupling configuration encoding (code gen, serialization, etc.) > > from lifecycle > > intialization processes. If these are kept separate (by keeping > > the config info > > in a config object that could be serialized) and the lifecycle > > part of the > > Embedlet contract, you end up with a hybrid system that allows > > you to serialize > > the important config info if that is how you want to package and > > deliver it. > > > > > So all of the config, initialization and lifecycle state > > > information is then serialized, transfered to the target > device and then > > > deserialized. I guess I am just going to have to see all of > > this stuff fail > > > like you say it will with my own eyes in order to believe it. > > > > Se above....you STILL need the lifecycle initialization to take > > place. The > > serialized object graph does NOT help you with that at all. > > > > The point is that serialization is great for packaging static > > data, but is not good > > for representing dynamic, temporal processes. What I have > tried to do is > > propose a solution that allows for serialization for what it's > > good for (config info, > > which is just static data for the most part) and doesn't try to > > use a hammer to > > pound in a screw (using serialization for the temporal lifecycle > > intialization > > process). Gotta use the right tool for the job. > > > > The container specification will allow the use of serialization > > as a packaging > > solution for those container implementations that wish to use it. > > > > Anyway....I'm less set against serialization than I was, provided > > it is used for > > what it is good for with this "hybrid" approach. Still at 0- > > vote on serialization. > > (which is way better than -666, eh Ted <grins>). > > > > > > > It is just so difficult for me to take on faith that serialization > > > does not make sense when the new BeanBuilder application: > leverages the > > > new Long Term Persistence API to do all of the things that you say > > > can't be done. > > > > Look at the name of the API. Long Term Persistence! That > > implies you are > > storing data for long periods. It has NOTHING to do with > > temporal or lifecycle > > processes like initialization (of hardware, threads, etc.), and > > is not designed for > > that purpose. It is also designed for Long Term > > persistence.....short term > > persistence (using the term as Gregg had, meaning a "scratchpad" where > > embedlets have some data they need, including pre-set config > > info) is better > > implemented using property name/value pairs only and does not need any > > long term storage or XML encoding. > > > > > Embedlets have some attributes that are much closer to > > JavaBeans than any of > > > these other technologies have so I do not know how one can use > > them to show > > > that serialization for packaging and deployment purposes is a > defective > > > technique. > > > > It is defective if you try to mix data and process together using > > serialization. > > > > Yes.....many attributes (especially initial config info) of > > Embedlets are very > > much like JavaBeans. And that is exactly how they will be > > implemented...but > > using a generic property capability (rather than method naming > > standards and > > introspection as JavaBeans do, meaning we will haveonly two methods: > > setProperty( String name,Object value ) and getProperty( String > > name ) ). > > That's what the context (eg. config) objects that are given to > > Embedlets will do. > > They will simply be data repositories....with NO business logic > > or process, and > > so they are easily serializable without impact on anything else. > > The embedlet > > code would then provide the business/process logic, including > > interfaces that > > the lifecycle service would invoke. > > > > > First off Servlets are not a component technology so I do not think > > > that they can be used for comparison here. > > > > Give your head a shake, Ted. ;-) Servlets ARE components....but > > they are > > process-based components, not data components! Container based systems > > (like Outpost/Embedlets and Servlets) manage process-based components. > > > > However, they (Embedlets/Servlets) are not, nor should they be > data-based > > components (which represent real world entities). JavaBeans are > > primarily > > data components (though they have an ugly event/change > propagation system > > that is rarely used these days). > > > > Serialization is great for data components. It sucks for process based > > components. > > > > Hence my proposal to split an Embedlet into two related but > > decoupled pieces: > > > > 1) Context objects = Data-based components that are easily > > serializable since > > they have no temporal/process semantics. > > > > 2) Embedlets = Process-based components which are easily managed in a > > temporal lifecycle since they have no intrinsic data semantics > > and thus have > > no need for serialization. > > > > By splitting it up we get the best of both worlds, and we get the > > ability for the > > container to manage threads (or not if they are not supported) > > almost for free. > > > > > As for EJBs and Avalon components, > > > point me to where I can see object graphs of 10 to 100 EJBs or Avalon > > > components wired together in a JavaBeans-like configuration and I will > > > certainly take a look at it. > > > > OK...let's think about this. EJB's or Servlets are components akin to > > Embedlets. Typically they are "glued together" into a full > > application using > > procedural code, which does not really compare to the declarative way we > > want to do it (or with a Graphical Wiring tool that generates the > > declarative > > wiring specification in XML). However if you look at commercial > > BPM engines > > (business process management), they do glue things like Servlets > > and EJB's > > (and web services, JMS message queues, etc) together. Typically using a > > declarative specification and a graphical wiring tool to create > > the process > > definition. None of these implements EJB's or Servlets are > > serialized object > > trees and probably never will, since it is fraught with the > > problems I have noted > > before. More fundamentally, EJBs and Servlets are process-based > > components....not data-based ones, so serialization doesn't make sense. > > (Note that stateful session beans have an intrinsic data > > component, the state, > > but are rarely used since they don't scale well, and Entitiy > > beans are just a > > facade for a real data store....so are more like the Persistence > > Service than an > > Embedlet). > > > > However, this is maybe not a good example. So go look at the Struts > > framework (The new Programming Jakarta Struts book from O'Reilly is an > > excellent way to learn about Struts). It does exactly this kind > > of wiring. You > > create a bunch of independent components, including: Actions, > > ActionForms, > > Value Holders (JavaBeans), JSPs, Tag libraries, Resource bundles > > and more. > > You "wire" these into a complete application, including the much of the > > specification of the flow or process of the application, in the > > struts-config.xml > > file. Everything is highly decoupled. They use the Jakarta > > Digester to read the > > config file and place the data into runtime config/context objects. > > > > Now....this config file can get rather complex as you can imagine > > (as might a > > complex embedlet-based application) due to the number of components and > > the wiring required and it can be tedious to hand-code the XML. > > A Graphical > > Struts Config tool has been created to ease this task: > > > > http://jamesholmes.com/struts/console/ > > > > It is more a treeview type of thing, not a drag/drop wiring tool > > like the one you > > have envisioned for Outpost, Ted, but the concepts are almost identical. > > > > What is noteworthy about Struts as an example, is that it is a > fairly new > > framework for this kind of thing, and is regarded as one of the > > best architected > > MVC frameworks for use in a J2EE Container-based system. If > > Serialization > > offered any appreciable benefits, then I think they would have > > used it....but > > they didn't. > > > > The upshot of all this is that there are many container based > systems out > > there. None use serialization typically for their config > > process, they all use > > XML config files. And look at one of the most highly regarded > > frameworks in > > this area, Struts. There are NO such containers that use > > serialization that I > > know of, and historically the only one that did (Smalltalk) had massive > > problems with that approach and failed in the marketplace. > > > > That doesn't mean that serialization can't work (my hybrid > proposal would > > mitigate the issues with serialization and looks very viable, and > > our spec > > should allow for it's use), but as a betting man, which one you > > want to put your > > money on: A solution that has a proven track record, or one that > > has no or a > > failed track record? That's a rhetorical question in my mind, > > Ted. <grins> > > > > Above all, I hope my observation on data-based versus process-based > > components sheds some light on this issue of where we could/should use > > serialization, and where it does not apply. > > > > But take comfort and get your fork out, Ted, 'cause just as with > > graphical > > wiring, you can have your serialization cake and eat it too with > > my proposed > > design concepts. ;-) > > > > > > > > > > > > Andrzej Jan Taramina > > Chaeron Corporation: Enterprise System Solutions > > http://www.chaeron.com > > > > > > > > ------------------------------------------------------- > > This SF.NET email is sponsored by: > > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > > http://www.vasoftware.com > > _______________________________________________ > > Embedlets-developer mailing list > > Emb...@li... > > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > > > > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > Embedlets-developer mailing list > Emb...@li... > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > > |
|
From: James C. <ca...@vi...> - 2003-02-10 23:39:33
|
> IMO our embedlet architecture as it is now, is a little too much like a > servlet architecture, and I don't think it fits the environment as well as > it should. > I think it would be far better to do things the other way around, so that > the outpost device was sent its configuration, and then sent its data back > out to it's "listeners", similar to a subscriber pattern. This would mean > that the embedded devices could do their work in their own time frame, as > fast as they can reasonably do it, while not getting tied up servicing a > single request. In the current architecture the 'real-time' components are JAPL components. In my imagining, JAPL components which are very much like, if not exactly like, cork components will likely have Event driven orientation. I think embedlets are subscribers to JAPL components which have event generators for which Embedlets are listeners for sure. In this way all real-time is handled by the container and the real-time features of the platform. Again though, the embedlet implementation may use no JAPL components at all! It may simply be a logic configuration and not be a real-time system. James Caska http://www.muvium.com 'Java Bred for Embedded' > -----Original Message----- > From: emb...@li... > [mailto:emb...@li...]On Behalf Of > Brill Pappin > Sent: Tuesday, February 11, 2003 5:46 AM > To: emb...@li... > Subject: Re: [Embedlets-dev] [Arch] Management of embedlets > > > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > _______________________________________________ > > > > I'd narrow that down a little I think... for the most part an Embedlet > > > would be talking to/gathering data from a single device, so maybe the > > > embedlet should be a singleton... also helps reduce load on > the embedded > > > environment by not trying to do to much at once. > > > > I don't see any reason why we should limit an Embedlet to talk to one > device, > > arbitrarily. As for singletons...in a threaded system, you > wouldn't even > have > > I disagree with that, singeltons have their place in any > development... most > useful when you wnat to make sure an environment has only one > instance copy > regardless of how the implementation runs. I see it as good programming > pratice to protect the areas of code that need it, against poorly written > implementations. > IMO never depend on 3rd parties to do your work for you ;) > > > > For instance, on the physical level in Cork, only one device can be > > > talking over I2C at any one time, so the underlying code > allows the bus > to > > > be "locked" for any other requests, it also takes the addresses of the > > > available devices into account because you can't have more > than one with > > > the same address (in certain circumstances you can, but in > that case it > > > would be the same device as far as the software was concerned). > > > > Assuming it's a polled device, the Timer Service would create a periodic > event, > > which an Embedlet would be listening for. The Container would then call > the > > embedlet's event processing method with the timer event. The embedlet > > would lock the bus, poll the device, unlock the bus, possibly do some > other > > processing (send a device-specific event based on the value it got) and > would > > exit. > > I think you have to be careful here, as not all external devices return > immediatly... for instance a 1-Wire net with a heavy wieght and > radius could > take several seconds to properly search, which is an eternatiy in > electronics. I2C is much faster, but till may take several hunbred > milliseconds depending on the device (the Devantech SRF08 will > take from 70 > to 100ms to return a single ping). > > > > Anyway, I don't think its really required that the embedlets > behave that > > > way, as the container can do the work of requesting data as needed... > > > however the embedlet should take into account that the container can > only > > > do things one at a time (for the most part). Anyway, quick, > low traffic > > > requests are important here. > > > > Not sure what you mean by this. The Container only manages > Embedlets....it > > would not be it's responsibility to talk to a JAPL/Cork interface. > (Separation of > > Concerns). The only time a physical device and Container would > interact, > > would be in the case of an interrupt drive device. When the interrupt > came in > > the JAPL code would use a static Container method to get a handle to the > > Event Service, so it could post an Embedlet Event into the queue. > > What I was thinking is that the container could to all the talking in the > background to lower level stuff, and make the data availible to > the embedlet > when it needed it... or the embedlet could request some specific data from > the underlaying code (or the container) and receive a callback > whent he data > was actually delivered. > > > > The other option of course is to dump the data elsewhere (into a DB > maybe) > > > and allow the embedlet to redirect requests, or be used only for > outgoing > > > transmission (and not service requests on its own). > > > > Not necessary (and DB's won't typically be available on an embedded > device). > > The event queues effectively provide the capability you need (for > transient > > storage and linkage between a device, Embedlet and Container, but in a > > decoupled manner). > > I agree, although I think it important that the device not have to respond > to the embedlet in the embedlets timeframe. so everything must be loosely > coupled so that the underlying system is not tied up trying to service a > single embedlet request, at the expense of all else it must do for normal > operation. > > IMO our embedlet architecture as it is now, is a little too much like a > servlet architecture, and I don't think it fits the environment as well as > it should. > I think it would be far better to do things the other way around, so that > the outpost device was sent its configuration, and then sent its data back > out to it's "listeners", similar to a subscriber pattern. This would mean > that the embedded devices could do their work in their own time frame, as > fast as they can reasonably do it, while not getting tied up servicing a > single request. This is somewhat how I thought it was to work, but I'm > getting the idea recently that every request is polled from the outpost > device... which will work up to a limited weight, but is a fairly > significant point of failure as the outpost network grows (which is the > problem we're attempting to solve here). > > - Brill Pappin > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > Embedlets-developer mailing list > Emb...@li... > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > > |
11 messages has been excluded from this view by a project administrator.
Thanks for helping keep SourceForge clean.
X