RE: [Embedlets-dev] [Impl] Initialization process: Code Gen vs. Serialization
Status: Alpha
Brought to you by:
tkosan
|
From: James C. <ca...@vi...> - 2003-02-10 23:41:40
|
>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 > > |