RE: [Embedlets-dev] [Arch] Persistence vs. Management

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

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?

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.

James Caska
http://www.muvium.com
'Java Bred for Embedded'






> -----Original Message-----
> From: emb...@li...
> [mailto:emb...@li...]On Behalf Of Ted
> Kosan
> Sent: Sunday, February 09, 2003 6:38 PM
> To: emb...@li...
> Subject: [Embedlets-dev] [Arch] Persistence vs. Management
>
>
> Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
> _______________________________________________
>
> James stated:
>
> > Ted's original vision was to have the Embedlet container be
> able to accept a
> > serialised stream representing the instantiated application embedlet
> > heirachy all in one go. I quite like it, the container only
> needs to be able
> > deserialise, the task of serialisation is done by the
> management tool and
> > all you need is some communications link to 'upload' the
> serialised embedlet
> > application. It is certainly quite an elegant approach.
>
> Well, you know, I thought it was an elegant approach.  A serialized object
> graph only contains each object's state information (just
> instance variable
> settings are included, no code is sent with serialization).  What can be
> simpler than having a target system read what the state of each object's
> instance variables are and then reconstituting it based on this
> information?
>
> The TINI/TStik already supports this now through ObjectInputStream and
> JStamp/JStik will be supporting it soon.
>
> As for the serialized object graph versioning problem that Gregg
> pointed out,
> this is the well documented weakness of trying to use the
> original *binary*
> version of object serialization for long term persistence needs
> (and hense all
> the warnings in the API docs about not using it for long term
> storage).  The
> new XML based Long Term Persistence API has completely fixed this
> problem and
> now Sun strongly recommends using the LTP API for saving object
> graphs of any
> kind for any purpose for any length of time.  In my opinion they
> have made this
> API bullet-proof and I strongly suggest that skeptics have a
> closer look at it
> before rejecting this idea.
>
> For the purposes of getting a serialized object graph into an Embedlet
> Container an object graph would only need to be converted into the binary
> serialization format for the short span of time it takes to
> transfer it to an
> Embedlet Container.
>
> Perhaps James and I are missing something here but since the Long Term
> Persistence API has fixed the versioning problem I do not see the
> downside of
> using object serialization as a lightweight method for getting an
> application
> into an Embedlet Container?
>
>
> Ted
>
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> http://mailplus.yahoo.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
>
>