RE: [Embedlets-dev] [Impl] Initialization process: Code Gen vs. Serialization

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

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