RE: [Embedlets-developer] Re: Embedlet comments

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

>However, many components and even more funcational
>embedlets (with application logic in them) will need to be built using
classic
>Java development techniques first. Bit of a chicken and egg scenario there.


Unfortunately, the chicken and egg scenario is a SERIOUS issue for this
whole project.

'Build it and I am sure they will come'

But who the hell is going to build the biggest most generic resuable freely
available embedded resource on the planet!! For nothing!

That is the real issue here. Without weaving some commercial sense into this
in some way (ie without rejecting commercial interests immediately without
thought) then this challenge just keeps getting bigger.

JC


> -----Original Message-----
> From: emb...@li...
> [mailto:emb...@li...]On Behalf Of
> Andrzej Jan Taramina
> Sent: Monday, January 27, 2003 9:20 AM
> To: emb...@li...
> Subject: [Embedlets-developer] Re: Embedlet comments
>
>
>  From Ted:
>
> > It is my opinion that if we are able to bring a
> >  simple,  platform-independent, snap together component
> >  market to the embedded space that it will be a huge
> >  success.
>
> I agree with you, but to be successful you need lots of pre-built
> components
> first.  That requires standard interfaces/contracts and a
> Container specification
> (and some implementations for common platforms, PC/JStamp/uVM/etc) first.
>
> If you do the design of the Container and component contracts
> well, with a
> solid XML configuration vocabulary, then layering a sexy
> graphical UI on top of
> that is pretty easy.  However, many components and even more funcational
> embedlets (with application logic in them) will need to be built
> using classic
> Java development techniques first. Bit of a chicken and egg
> scenario there.
>
> Designing a container and the contracts it needs (eg. interfaces,
> lifecycles,
> etc.) that will eventually support this vision is a non-trivial
> task, especially since
> it needs a lot of flexibility to handle the wide range of
> platform capabilities and
> constraints that we are targeting.
>
> >  I do not personally have any problems with the XMLDOM route
> >  but my primary goal is a huge market of Embedded Components
> >  that can be graphically wired together by a 'Component
> >  Assembler' class of application developer.
>
> I believe that the design of the Outpost container/component
> architecture will
> be the critical piece of the technology puzzle here, with a
> graphical UI being
> some nice sex/sizzle for later.
>
> Many people have tried to float graphical assembly tools....but
> for the most
> part they have not succeeded (JavaBeans are a good example of
> this).  Most
> real-world problems require custom logic....which is where the graphical
> assemblers break down.  And trying to create a graphical programming
> language is probably not going to succeed in the short term.
> Look at how all
> the current containers work....all XML-based config files....nary
> a graphical
> assembly tool anywhere to be seen, though these might start to
> appear as the
> configs stabilize, container best practices solidify and the
> configs get complex
> enough to warrant such tools
>
> As for DOM....it won't ever fly on an embedded platform.  Too much memory
> overhead in instantiating the XML parse tree.  On embedded
> platforms, event
> based (SAX) XML parsing makes much more sense.  For the construction
> tool, that builds the glue that binds the container/components
> from the XML
> config, almost any XML parser can be used, since that process
> would likely be
> done on a more capable box (like a PC).
>
> > Yes, flowchart based programming has been around for years,
> >  but the killer idea here is that the Embedlet standard can
> >  allow a *huge* market for platform-independent, reusable,
> >  pre-serialized embedded components to be created.  The new
> >  XML based long term persistence format makes this feasible
> >  now.
>
> I'm not convinced that a JavaBeans approach with serialized instances is
> really that valuable.  It hasn't succeeded in the more classic
> Java space.  What
> seems to have garnered favour and market share is writing code to a
> container spec (eg. servlets, embedlets, EJBs) and specifying the
> "instances"
> that need to be created in an XML config file instead.
>
> The argument for a huge market for serialized components never
> materialized
> in the Java world....so I am quite skeptical that it will do so
> (at least in the
> shorter term) in the embedded world.  More likely that an
> Embedlet Container
> approach that is reminiscent of Servlet (and other) containers would gain
> traction and usage a lot faster.
>
> >  The Component market is the 'holy grail'.  The wiring tool
> >  is just a support technology for this market.
>
> That's what they said about J2EE (and EJBs), and about JavaBeans before
> that...but it hasn't really materialized.  How would the embedded
> space be
> different?
>
> > So, I propose VPL (Virtual Peripheral Library) as the
> >  official name.  What does everyone think?
>
> For what pieces of the Outpost/Embedlet puzzle?
>
> I see device drivers (or virtual peripheral drivers) as just
> special cases of an
> "embedlet".  One that may need regular polling (or a separate thread of
> execution where supported), and that would primarily produce Embedlet
> Events that are lower level/hardware oriented (eg. bit values,
> streams, etc),
> but might respond to control events as well.
>
> It may make sense to distinguish "embedlets" which contain
> application logic,
> from "device drivers" that sit next to the hardware.  But there
> is some overlap,
> if you use the Event model to glue the two together (with the Event
> Management provided by the container itself).
>
> 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
>
>