[Embedlets-dev] Re: More on "serialization"...

[Andrzej J. T. <an...@ch...>]

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