RE: [Embedlets-dev] RE:[Arch]New version 1.3 of the Architecture Discussion Document posted in CVS..
Status: Alpha
Brought to you by:
tkosan
|
From: James C. <ca...@vi...> - 2003-02-10 13:35:10
|
Ted, These are just different views of the same thing (which is why there is no silver bullet) In Scenario A, where the container and all the classes are loaded at the same time and it makes sense for the application to have a new 'program' uploaded dynamically then it makes sense to have the container and classes pre-installed. An examples of this would be a PLC, whereby the classes of all the 'components' of the PLC are preinstalled and the new ladder logic diagram is uploaded by serialisation. However, we may be loading more classes than are needed for all applications but in this instance it is significantly faster to upload a new 'embedlet configuration' - for one thing the serialised version may not need to hit the FLASH which means is a RAM transfer so new programs can be configured almost instantaneously. I can think of reasons to swap out whole programs' - almost like a thread transfer - to reconfigure the resource limited device. Scenario B, where we statically configure requires the more resource intensive full build process, has to hit the slow flash, but has the advantage of only storing exactly what is needed and only binding exactly the classes required. I think it is perfectly reasonable to support both Scenario A * Possibly Non-Optimal class storage requirements * Fast Serialised RAM Only Reprogramming ~Second(s) * Minimal programming interface (Serialisation API Only) Scenario B * Optimal Class Storage * Slow Reprogramming FLASH program reprogramming ~minute(s) * Resource intensive Build process for optimal configuration Each with advantages and applications. James Caska http://www.muvium.com 'Java Bred for Embedded' > -----Original Message----- > From: emb...@li... > [mailto:emb...@li...]On Behalf Of Ted > Kosan > Sent: Monday, February 10, 2003 9:14 PM > To: emb...@li... > Subject: [Embedlets-dev] RE:[Arch]New version 1.3 of the Architecture > Discussion Document posted in CVS... > > > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > _______________________________________________ > > James stated: > > >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. > > One thing that I have been wrestling with since I started > experimenting with > the Elevator challenge was which of the following scenarios made > more sense: > > A) The Embedlet Container for any given device would be > pre-installed on that > device and then the Embedlet application would be deployed into it as a > separate operation. > > B) The workstation that was being used to build the application > would start > with a default minimal functionality Embedlet Container, have > JAPL peripherals > and Container Services plugged into it as needed, have the > Embedlet application > assembled and installed into the container, have the system as a > whole Unit > tested and then have the complete system (Embedlet container and > all) packaged > into the target system's proprietary deployment format and then > sent to the > target device. > > For a TINI, the deployment file is called a .tini file and it contains an > application's compressed .class files. The way that a .tini file > is deployed > to a TINI is through FTP and one way to execute the application is through > telnet. > > > So, is the Embedlet Container pre-installed on the target device > or does it get > installed with the application? Are there compelling reasons to > allow for both > scenarios? > > > Ted > > __________________________________________________ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > http://mailplus.yahoo.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 > > |