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

[James C. <ca...@vi...>]

Andrzej

>you still need the class files as well.

There is no way around this on pretty much any embedded platform
irrespective of the persistance strategy. The new class files are going to
have to be uploaded by ftp(TINI/TStick) or UART/WebServices(uVM) or
JTAG(JStamp). I don't see a transportable version of classes for any of
these platforms so yes, we can only be talking about instances.

>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).

I am not sure what you mean, loading pure executable bytecodes, is not
possible on any of the embedded platforms. They all have some transform over
the bytecodes first. uVM compiles it, TINI transforms to .tini , and JStamp
obviscates it. You will need to spell out your vision on this a little more
concisely.


> 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 i

Of course I like the approach of doing the work on the 'Build Side' This is
a good thing and I also really love XML in fact I am not sure this is an
EITHER/OR box to tick. I have a feeling these are side by side techniques
for Embedlets.

As for versioning, each platform is going to have their own unique
serialisation format anyhow. THe idea of versioning for an embedded platform
is substantially reduced becuase of this fact, ie you are not likely to want
to upload a serialisation object for a TINI and try to run in uVM and vica
versa. What you are going to see is some sort of API layer that transforms
into the appropriate format before it is uploaded. Any versioning issues
will have to be handled by the vendor at this point of serialisation. My bet
is TINI does this already. There is nothing to stop this API from processing
the XML to generate the platform specific serialisation for the container.

But yet, I agree that this is just a snapshot - it doesn't handle
lifecycle's it is more the 'start conditions' which is why I think these
ideas work together. Serialisation for 'instantiation', Management for long
term persistance of only the minimal peices of data, the delta, that
actually need long term persisting.

Ie to start over at any point in time,

1) Container Instantiates serialisation tree
2) Container PropertyBag overlays 'delta' Management for long term
persistable data

In this way
1) The XML can still fully describe the persistance
2) The versioning is handled by the vendor specific 'Serialisation API'
which transforms the XML into the serialisation heirachy which is done at
build/link/application upload time
3) The long term persistance can be managed by delta Dynamic property
get/set into a containers property bag
4) If you want a complete snapshot for external representation you toXML()
the containers propertybag and combine it with the original XML that was
used to generate the serialisation tree back at the server side which can
then be reserialised if need be and uploaded as new 'start condition'

Hence the container has the following minimal capabilities.

instantiateEmbedletSerialisation(InputStream)
PropertyBag.getProperty()
PropertyBag.setProperty()
PropertyBag.toXML()

And all embedlets access the PropertyBag to store their delta state
conditions.

> My vote stays at -666 for Serialization as a packaging approach. ;-)

My vote is
-1 for Serialization as a exclusive packaging approach
+1 for a Hybrid Serialisation packaging approach


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: Monday, February 10, 2003 6:37 AM
> To: emb...@li...
> Subject: [Embedlets-dev] Re: More on "serialization"...
>
>
> Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
> _______________________________________________
>
> 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
>
>
>
> -------------------------------------------------------
> 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
>
>