[Embedlets-dev] Re: More on "serialization"...
Status: Alpha
Brought to you by:
tkosan
|
From: Andrzej J. T. <an...@ch...> - 2003-02-09 19:39:34
|
James: > One really nice possibility I really like for muvium at least is the idea > of being able to store the serialised form into FLASH of perhaps a > multitude of different 'precofigured' Embedlet applications and > instantiate the appropriate embedlet application from Flash in serialised > form upon demand. Can think of some cool idea's for this, like swapping > out entire embedlet applications for say Specialised Error Handling, or > different wiring configurations for different onboard applications, or > even PipeLining Stages of processing, who knows? There are some issues with this....you can't do this with just the serialized objects (stored somewhere)....those are just instances....you still need the class files as well. But that requires that all potentially used classes be loaded right up front (big footpring overhead) or that they can be dynamically retrieved from storage (eg. Flash) but then you need dynamic classloading. And you get all the baggage/issues of using serialization as an application/component packaging approach (per my other email on the subject). > I know this is all persistance stuff but enabling the embedlet container > to just suck up applications off a serial stream might prove useful in > lots of different ways without having to support layers of XML parsing > etc. The functional concepts very valid and would be a great capability, no question there. And the Arch discussion document addresses these requirements through the use of the Lifecycle Service in conjunction with the optional Management, Persistence and Dynamic Classloading/Config services. In fact, there could be no XML whatsoever involved in the loading of an app.....since the Build process could/would do the parsing on the workstation side first and code generate pre-populated instances, tables, control structures that were needed to run a particular app/component, and all you would be loading onto the device was pure, executable bytecodes with no embedded XML whatsoever (for those platforms where XML parsing and dynamic config on the device itself would be problematic). Funny thing....this would be "lighter weight" (at the Container end, at the the expense of a Build process is a bit more complex) than even a serialization/deserialization process (faster load/initialization time, no need for serialization/deserialization code on the platform, no need to store both the serialized and deserialized forms in memory simultaneously so lower memory footprint). It also mirrors the uVM approach....all the "heavy lifting" of creating and packaging the app to it's smallest possible runtime footprint (with all extraneous stuff pared away) can be done by the Build process (except when dynamic config is a key requirement,in which case you consciously choose to accept the overhead of doing some of the dynamic stuff in the Container). I 100% agree that we need Persistence, Management, Dynamic Config optional services (let's not forget...this stuff has to be optional/modular, so the developer/deployer only selects the services they need for their particular application and platform constraints and we can target the widest possible range of platforms/applications). I just don't think serialization is the best way to implement these features/services. My vote stays at -666 for Serialization as a packaging approach. ;-) Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |