embedlets-developer — Outpost Embedlet container developer list

[Embedlets-developer] Re: Back to the roots...

[Andrzej J. T. <an...@ch...>]

James said:

> I also agree it is a good idea to pick one high value thing and solve that
> problem while being mindfull of other applications. The Enterprise
> wide-fan concept is where this all began and has many compelling reasons
> for that so it may be time to 'get back to roots' shortly.

Man....James and I are in 110% agreement on a point.  I think I have to go get 
a scotch and ruminate on this...scary! <grins>

Though there was probably no need to quote my whole (rather long) post just 
to make the above top-posted point. ;-)

Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com

RE: [Embedlets-developer] Re: Design Thoughts (reponses to Ted's points)

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

>I think this wiring should be specified by an XML config file.  Which in
turn
>could be generated by a graphical tool for those that are so inclined.

I do tend to agree with this. I have used this approach in the past also in
VBB and in other projects. It has also been used successfully in many other
places, particularly HTML/Browser, SVG/Viewer etc.

The one thing this approach does is to create a dictionary that everyone can
refer to and understand in a readable form. If we left this part to the bean
persistance model it would become transparent and I think we would loose
many benefits of the formalness of the underlying XML document.

Nevertheless, I am totally on-board with the idea of wiring for embedded
applications and with the philosophy of technician's being used to scale-out
large installations. Don't forget that embedded are very familiar with
wiring as a 'programming' style because they do it all the time with their
PCB's and schematic design. This is somewhat different to the pure java
market. EMbedded are also more familiar with 'components', every integrated
circuit is actually a component. Finally, we are talking about wiring
together applications consisting of pre-build embedlets rather than for
building the embedlets themselves so I think the wiring approach works in
this place.

>That is a risky target.  I would be happier just addressing the "pyramid"
>problem of getting an enterprise "wired" so that info flows from the shop
floor
>right up to the enterprise systems (from embedded controllers to
concentrators
>to server-side enterprise systems) as the initial primary goal.

I also agree it is a good idea to pick one high value thing and solve that
problem while being mindfull of other applications. The Enterprise wide-fan
concept is where this all began and has many compelling reasons for that so
it may be time to 'get back to roots' shortly.


James



> -----Original Message-----
> From: emb...@li...
> [mailto:emb...@li...]On Behalf Of
> Andrzej Jan Taramina
> Sent: Tuesday, January 28, 2003 4:56 AM
> To: emb...@li...
> Subject: [Embedlets-developer] Re: Design Thoughts (reponses to Ted's
> points)
>
>
> Ted sed:
>
> > All the design documents are in OpenOffice 1.0's XML file
> > formats so they can be managed by a CVS system very easily.
>
> That's very cool.  I installed StarOffice a while back, but
> haven't used it much.
> This might be a good excuse to do so.
>
> > Embedlet logic can be developed using:
> >
> > 1)  Java.
>
> That's probably a given.... <grins>
>
> > 2)  PICBASIC.  For people who are not skilled Java developers
> there is no
> > reason why a PICBASIC interpreter Embedlet could not be created and then
> > people who know how to program in PICBASIC can easily develop their own
> > Embedlet logic.  If Embedlets are capable of being graphically wired
> > together using a wiring tool then these people will not even necessarily
> > be aware that they are using Java at all.
>
> I think that anyone that can figure out how to use PICBASIC
> should be able to
> use Java in a simple scripting mode.  But maybe I am mistaken on
> that....and
> regardless, you are correct that an interpreting embedlet could
> be written quite
> easily.  Better still, would be a code generator that took PICBASIC and
> translated it into Java, which would then be compiled.  Better
> performance that
> way on limited devices.
>
> > 3)  LADDER LOGIC.  If Embedlet logic can be developed in
> PICBASIC why not
> > allow it to also be graphically developed using LADDER LOGIC?
>
> It could...but I don't think that should be the initial focus of
> our efforts. Once we
> have a few Outpost/Embedlet containers running using Java, then
> we can see
> what makes sense in the way of additional language/scripting support.
>
> > The deeper that I dig into developing a solution to the
> Elevator challenge
> > the more I am convinced that Embedlets are capable of elegantly
> > accommodating an extremely diverse set of needs.
>
> Embedlets are just a container design for limited devices, with a full
> programming language included (Java in this case).  With that
> flexibility you
> can implement anything that is Turing Complete.  The question is not can
> we....but should we, and if so, when?
>
> > most people seem to have forgotten that
> > JavaBeans were originally designed as a general purpose
> software component
> > technology capable of supporting a large software component market for
> > people that wanted to graphically wire applications together.  Beyond
> > this, with EJBs and the enterprise market taking off like it did there
> > were little resources or desire to pursue the original JavaBeans vision.
>
> I would add that there has not been any substantial market demand
> for such
> graphical programming/assembly tools.  On any platform (not just
> Java).  Even
> with COM components and VB assembly, the issue you come down to is that
> custom application logic has to be coded in a programming language (and I
> don't see that changing in the near term....Java/C/C++/Perl/Basic
> aren't going
> away for a long time).  And as soon as you have to write code,
> the benefits of
> switching to a graphical tool for part of your work lessens substantially.
>
> > The new BeanBuilder tool is open source and I would like to use
> it as the
> > foundation for the initial proof-of-concept Embedlet Wiring tool.
>
> I have no issue with that.  So long as the GUI tool creates the
> underlying
> Embedlet XML config file that can be then pumped through the Embedlet
> configurator/builder.  But somehow I think this will be a
> philosophical sticking
> point....
>
> > We are in complete agreement here.  The Embedlets themselves
> will often be
> > very complex and so they will probably be developed in Java by skilled
> > Java programmers.  The graphical wiring capabilities are just
> for allowing
> > non-programmer application assemblers to assemble applications using
> > standard software components (Embedlets).
>
> If all you are doing is simple wiring, then having the GUI
> generate an XML
> Config file that specifies the "glue" is not that hard to do.
>
> > I agree that the container could offer standard services but I
> think that
> > the services should be pluggable so that if one wanted to put a minimal
> > service Embedlet Container in a uVM it could be easily done.
>
> Absolutely....as many services as possible need to be optional.
> The ones that
> would be mandatory would include Event Management, Component Lifecycle
> Management and Scheduling (more on the scheduling issue later).  Optional
> ones could be: Logging, Management (JMX), and others.
>
> > I think that we will need to discuss this point further.  I
> think that if
> > a non-programmer application assembler is developing an Embedlet based
> > application then they should be able to do so by directly wiring the
> > application together using a graphic wiring tool (which is a technique
> > that has been proven to work well by JavaStudio and the various versions
> > of the BeanBuilder).
>
> I think this wiring should be specified by an XML config file.
> Which in turn
> could be generated by a graphical tool for those that are so inclined.
>
> I'm still nervous about the graphical construction approach,
> since it has never
> succeeded in the marketplace, whereas XML-based configuration capability
> has.
>
> > I do not see why we can not provide both mechanisms especially
> since they
> > seem to be complementary.
>
> There is no reason we can't do both....
>
> > So far the experience I have had with developing a solution to the
> > elevator problem indicates that quite complex applications can be
> > assembled by graphically configuring components and wiring them
> together.
> > I hope to have my solution available for critiquing within 2
> weeks so that
> > we can see if I am missing something critical.
>
> The XML Config specification, if it contains a comprehensive, standalone
> description of the config'ed app, would probably still be rather
> complex.  That
> is not a really big deal in my mind, since the XML would only be
> processed on
> a development workstation (eg. PC) and not on the embedded device itself.
>
> > The route that the wiring tool is taking is to allow the
> application to be
> > graphically wired together and then the application's complete object
> > graph is saved using the LTP API and then also deserialized into the
> > embedded system.  I have already successfully deserialized small
> > applications into a TINI as a proof of concept (it worked well) and I
> > think that this technique will work with the uVM too.
>
> I prefer a code-generated approach (for the most constrained
> devices) and a
> dynamic config approach (for more capable ones).  My gut feel is
> that it will
> provide more flexibility and performance that way, rather than
> using serialized
> instances.  The bean assembly approach (with it's serialized persistence
> metaphor) works well in scenarios where you have fewer classes than
> object....that is, when you instantiate many objects of a
> particular class.  This
> is common with apps that are UI based, where you instantiate
> visible widgets
> like text edits, scroll bars, labels, etc.  I don't see much
> value to that approach
> when you there aren't as many objects and the classes do most of the work
> (as would be the case with embedlets).  The level of complexity
> is reduced
> substantially, since there are not that many objects to
> instantiate, and the
> server process can do that based on the config info (rather than
> re-consititute
> a serialized instance).
>
> > I think that we should definitively prove that one Embedlet
> specification
> > is incapable of spanning the full spectrum of target environments before
> > falling back on multiple specifications.  I currently think that one
> > specification will be sufficient.
>
> I agree.  One spec.  But there may be many different container
> implementations based on that spec.  aJile chips have threads, so why not
> have a container that can leverage that?  uVM may not have threads, so a
> different container may be needed.
>
> > I think that, just like with security, if the graphical wiring
> capability
> > is not built in from day one that it can not be successfully be
> tacked on
> > afterwards.  In order to accommodate graphic wiring, Embedlets
> simply need
> > to permit their properties to be configured using setters and getters
> > (achieved mostly through naming conventions) and they need to allow for
> > the registering, unregistering and handling of events.  They
> should suffer
> > no more than normal JavaBeans have by being able to be using in
> a graphic
> > wiring tool.
>
> The graphical tool could just as easily set the property values
> in the XML
> Config file rather than using bean-based introspection and the
> like.  So that's
> not a big issue.  I think we can also build a container where the actual
> embedlet code can avoid registration/unregistration for events by
> having that
> registration handled by the container on the components behalf (we might
> want a way to unregister dynamically, though I think this will
> not be needed
> much since embedlets will typically listen to a small number of
> events all the
> time, and that might be better handled with lifecycle events).
> In any case, the
> simple cases should probably have such "plumbing" issues handled
> automatically based on an XML descriptor (as I had proposed),
> with a dynamic
> API available for the odd case that might be needed.
>
> > With JAPL, Embedlets can handle all possible 'peripherals' from simple
> > devices to the most complex backend system.  Again, this is shown in the
> > following simple Embedlet application (notice that it is hooked up to a
> > backend enterprise system):
>
> I don't think JAPL is necessarily a good way to abstract
> communication to the
> host systems (a specialized embedlet might make more sense for
> that).  And
> having a standard API for device access is a good thing, but
> there are some
> scheduling issues if you are running in a container environment.
>
> The focus of control of scheduling (and things like event
> management across
> multiple embedlets) is the Container.  So an embedlet should not grab the
> processor and keep it.  If the platform supports threads, then
> this is easy to
> implement (eg. PC's, aJile boards).  The problem is if you don't
> have threads.
> Then the embedlets need to use a co-operative processing approach where
> they relinquish control back to the container rather
> quickly...probably just
> responding to events as they get them.
>
> What if an embedlet needs to regularly monitor a bit on a
> physical device?
> Sure JAPL lets you use a nice abstracted API to get the bit.  But without
> threads, how do you construct an Embedlet that can do periodic
> tests using
> the JAPL API call?  It can't just do a delay loop with a test,
> since then the
> container and other embedlets won't get any processor time.  One
> way is to
> have a PeriodicTimerEvent that Embedlets can subscribe to receive.  And
> each time it receives such a timer fired event it does one test
> using JAPL and
> then does something useful (maybe posting a different event).
> This way you
> can have multiple embedlets running, without needing threads.
>
> I don't think that it would make sense to embed these kinds of "polling"
> semantics into the JAPL API.  Rather, we could have some standard
> "off-the-
> shelf" embedlets (and rather simple ones) that implement such semantics,
> basically talking to a device as required (whether polled,
> interrupt driven,
> threaded, etc.) and then translating the device data into a suitable
> EmbedletEvent that gets propagated further.  They would conceptually be
> "adapter" embedlets that translated between the hardware bits and the
> Embedlet Event paradigm.
>
> > My primary goal is not to get enterprise developers more
> comfortable with
> > embedded development.  My goal is to allow the semi-technical
> IT personnel
> > which are present in most companies to be able to graphically wire
> > together Embedded systems and attach them to backend enterprise systems
> > with minimal help from the the enterprise developers.
>
> This assumes that they won't need custom application logic on the
> embedded
> device.  That assumption might not hold very well in the real
> world, unless the
> scope of what embedlets do is rather reduced.
>
> > My thought was that the $25/hour IT personnel should not have to bother
> > the $100/hour enterprise personnel more often than was absolutely
> > necessary in order to attach the eventually large number of embedded
> > systems that companies will eventually need to be hooking to their
> > enterprise systems.
>
> If you are interfacing with enterprise systems, the enterprise
> guys will be
> involved.  No way they will allow anyone to plug just anything
> into the large
> back end systems.  Initially the end to end solution would have to be
> architected, which would involve everyone. Embedlets would be
> written.  After
> that, deploying more of the same types of controllers might be
> allowed, but
> initially I think it will involve everyone.  At best, the server
> side people will insist
> on massive integration testing.
>
> > In my scheme, the enterprise developers are primarily used as a 'back
> > door' method for marketing the Outpost idea to companies.  Even though
> > some of them might catch the embedded systems bug, I think that most of
> > them will not have the necessary background for interfacing embedded
> > systems to their company's processes.
>
> Maybe not....but they will be involved, and actively so, in any new
> implementation that interfaces with their back ends.  In fact, they would
> probably have to write new servlets (exposed as web services perhaps) to
> facilitate the integration, which means both side have to talk a lot.
>
> > Without graphic wiring capabilities Embedlets are not usable by my pet
> > target user base.
>
> I don't think we should be targeting non-IT end-users for Embedlets.  The
> reason IT exists is to translate user requirements into a logical
> flow...something most users are not great at.  Graphical tools
> don't really help
> that problem.  And plant-level IT folks are definitely capable of
> using XML
> based configurations and writing some simple logic.
>
> > I spent a significant amount of time digging into the dynamic proxy API
> > and it will only run on JDK 1.3 and up APIs.  Numerous classes
> in the API
> > were enhanced to accommodate dynamic proxies (like the
> serialization API)
> > and almost no embedded Java system are going to have these
> capabilities in
> > the near future.
>
> I was thinking of PC's....there is a lot of applicability for
> using stripped down,
> hardened PC's on the plant floor as both controllers or
> concentrators (Level 1
> or 2 as was defined in the SoftPLC article).  A minimal PC with
> linux and a
> JVM would make a great Outpost platform for many applications.
> And in that
> case, why not have a Container implementation that allows for
> more dynamic
> operations and leverage things like dynamic proxies, threads and more?
>
> My only point is that the Outpost specifications should not preclude such
> container implementations for more capable platforms.  But it should not
> require such advanced capabilities either.
>
> > Since all Embedlets that need to receive events implement one interface
> > there is no need for dynamic event proxies.
>
> There may be value in allowing an embedlet to receive different events
> through different methods.  It potentially gets rid of long
> Select/Case chains in
> the Embedlet logic, letting the container do the "routing" for
> the embedlet.
>
> > Simply have an Embedlet
> > register itself as an event listener for a specific type of
> EmbedletEvent
> > on any given target Embedlet and thats it.
>
> Better still, have the container register the embedlet as part of
> the initialization
> process, if the config says that the embedlet wants to receive
> certain event
> types.
>
> > I read through your event mechanism description and, believe it
> or not, it
> > is almost identical to the event mechanism that was developed
> for JavaOS.
> > I think the fact that you independently came up with an event mechanism
> > that is very close to the event mechanism that the pricipal designer of
> > Apple's PCI device driver architecture, Sun and IBM arrived at
> after years
> > of effort is significant.
>
> It's also very similar to best practices in the Messaging world
> (JMS) and event-
> driven windowing systems (which is where it all began).  This
> stuff has a large
> body of "best practices" out there.
>
> > Where our current approaches differ is 1) direct event registering
> > vs.using an event broker and
>
> There would still be an event broker (the container itself) in
> either scenario.
> It's just that letting the container (rather than the component)
> handle the
> registration might have some benefits, per my earlier comments.
>
> 2) having multiple interfaces for
> > registering event listeners on a event producer vs. having one generic
> > event registration interface for all producers.
>
> How about no interfaces (at least not mandatory ones) for the
> registration, and
> let the container handle that.
>
> >  I am
> > not sure how dynamic a typical embedded system needs to be.
>
> As soon as you have more than one embedlet running, you get into the
> scheduling issues I mentioned.  Which implies the need for a
> Scheduler and
> Event Manager (broker)....which I see as the responsibility of
> the Container.
>
> > I think that some more discussion on this topic and some experimenting
> > would be sufficient to clarify these two issues for me.
>
> Yup...
>
> > Is there any chance that I could persuade you to obtain a copy of the
> > JavaOS book (Inside the JavaOS Operating System, Saulpaugh and Mirho,
> > Addison-Wesley, ISBN 0-201-18393-5, available from Amazon) so
> that we can
> > discuss the merits of an event broker approach using a working
> and proven
> > example as a starting point?
>
> I don't think my schedule will allow it....and I don't think it's
> necessary.  Event
> and Message-based systems are something I know a lot about.
>
> > From the research I have done on JavaBeans it appears to me that the two
> > things that killed its potential for creating a large component
> market was
> > 1) the lack of a robust method for long term persistence of
> object graphs
> > and 2) an event mechanism that was not general enough to allow an
> > extremely wide range of software components to be easily wired
> together.
> > Number 1 has already been solved and I think we have an
> excellent shot at
> > solving number 2.
>
> I think #2 will still take some time, and will likely build on
> the work in the Web Services area to some degree.  The difficulty
> in wiring a wide range of components is that it invariably
> requires some custom logic....which is easier to do in a
> programming language than in a graphical tool.
> > As for EJBs, it seems to me that doing enterprise Java development right
> > is so complex that highly skilled Java programmers are absolutely needed
> > in order to 'knit' everything together.
>
> Hence the need for us to keep the embedlet spec and related XML
> configs as
> simple as possible.  We have an advantage, since most embedded processors
> will not need the same scalability, security, transactional and
> flexibility
> characteristics that are needed on the enterprise end.
>
> > If even the Java developers can
> > not agree on fundamental things like whether Container Managed
> Persistence
> > or Bean Managed Persistence is the best persistence mechanism
> to use then,
> > to me, this is an indicator that EJBs are not yet mature enough
> to support
> > non-programmer application assemblers.
>
> That has nothing to do with component assembly....and everything
> to do with
> the inflexibility of CMP in real-world situations, versus complex
> O/R Mapping
> tools typically used for BMP.  The EJB spec is also fundamentally
> flawed in
> that it mixes together a number of requirements that are
> orthogonal to each
> other, such as security, transactionality, scalability and
> persistence.  Note that
> the first three are typically cross-cutting concerns, whereas
> persistence is
> more localized.
>
> > The Embedlet space is looking like it is significantly simpler than the
> > EJB space and the more I work on a solution to the elevator problem the
> > more I am convinced that Embedlets have a real shot of being the first
> > Java software component technology to create a large and successful
> > component market.
>
> The issue of granularity also works against widespread wiring of
> finer-grained
> components....and we haven't even resolved and deployed solutions
> to wiring
> of much coarser-grained services (though the web services community is
> working on that).
>
> Past history with software component markets would lead me to
> believe that
> we are a ways from that.  If such a market arises, great...but I
> don't think the
> creation of such a market should be our primary consideration.
>
> > Over the past few weeks JAPL has been developed to solve the device
> > drivers problem.
>
> Where can I get more info on the JAPL API?  Does it resolve the
> co-operative
> processing of multiple components issue (polling) problem (which
> I think it
> should not....that should probably be left to adapter Embedlet components
> rather than complicate the JAPL API).
>
> > Could you draw up a model of the same application that uses an
> alternative
> > to JAPL to solve the device driver problem?
>
> It would look just like your diagram with the only exception
> being that I don't
> think the API should handle the host communications.  It should
> stick to being
> a VPL API definition only.  The point I am trying to clarify is
> where does the
> event scheduling happen, which is not specified in the diagram. I
> think it
> should be in the Sensor and Alarm Embedlets....using an approach
> similar to
> the "polling" example I mentioned above.
>
> > What do you think about creating a 'Taramina' folder in the dev_docs
> > directory of the CVS and placing your design work under version control?
>
> Sure...when I have something ready, but I would rather we set up
> a generic
> "scratchpad" area for such musings, rather than tie the folders
> to specific
> names  Most of this is still in napkin diagrams or in my head right now.
>
> > Together the JAPL specification and the Embedlets specification solve so
> > many of the embedded space's current problems that, if they succeed at
> > all, I think they will succeed in a very big way.  Thankfully, we are
> > mostly responsible for developing the open specifications and providing
> > open source reference implementations for them.  If these are
> done 'right'
> > then the embedded space should just naturally build to these
> > specifications just like the world built to the HTTP/HTML specifications
> > when they were first released.
>
> So the theory goes. ;-)
>
> > 1) Embedlets provide platform-independent embedded logic at the binary
> > level and  the Embedlet Container provides a virtual embedded
> system that
> > will allow embedded applications to be completely shielded from the
> > grueling platform churn and diversity that the embedded space is
> > susceptible to.
>
> The container should also provide some core services (and
> optional ones) so
> as to make embedlet code as simple as possible.
>
> > 4) All the I/O chip manufactures make similar competing chips that are
> > incompatible with each other.  For example, there are dozens of UARTS on
> > the market and they all need unique device drivers.  Even embedded Java
> > systems like the JStamp and TINI use proprietary classes for accessing
> > things as simple as an 8 bit I/O port.  JAPL solves this problem for the
> > application developer by coming up with one generic interface for each
> > chip/peripheral type.  Now, all client code is compiled against one
> > generic interface for each device type and then the task of developing a
> > device driver which will allow any specific chip variant, like an 8250
> > UART, to realize this interface is significantly reduced.  This
> represents
> > the successful JDBC model brought into the embedded systems world.
>
> Absolutely agree.
>
> > 5) It allows embedded systems to be graphically wired together by
> > non-programmer IT personnel.
>
> I see this as a "nice to have" in the short term.
>
> > 6) It enables the creation of a large software component market for the
> > embedded space.
>
> That is a risky target.  I would be happier just addressing the "pyramid"
> problem of getting an enterprise "wired" so that info flows from
> the shop floor
> right up to the enterprise systems (from embedded controllers to
> concentrators
> to server-side enterprise systems) as the initial primary goal.
>
> > 7) Perhaps the most compelling story that these specifications have to
> > offer is that they represent what I think may be the *first* wide scope,
> > open source community and technology to be targeted toward the embedded
> > space.  In an earlier post you were so right when you pointed out that
> > almost all the endeavors to date in the embedded space have
> been extremely
> > proprietary.
>
> Yup....that is a key benefit of our approach.
>
> > So, if JAPL and the Embedlet Container specification can
> actually succeed
> > in providing the first open embedded systems platform and community that
> > the whole embedded system's space can leverage, then I think it will be
> > extremely successful.
>
> It might.....but is still based on Java availability.  I think
> it's only now become
> feasible to deploy Java on smaller devices (aJile/Systronix
> leading the way
> here, and uVM coming soon hopefully), and so now we can leverage the
> ubiquity of Java down into the embedded space.
>
> > I think the embedded space is ripe for the introduction of open
> source and
> > I think we are in a position to significantly help with this.
>
> For sure!
>
>
> 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
>
>

Re: [Embedlets-developer] visual designer/wiring tool

[Jac K. <j.k...@th...>]

On Mon, 27 Jan 2003, Gregg G. Wonderly wrote:

> Yeah, I would have jump on that too, except they didn't have any way to 
> interact with my source code management system, and I couldn't checkout 400+ 
> files every time I wanted to work on the project...

There is CVS intergration available on sourceforge :-) We've been using it 
for almost two years before switching to eclipse a couple of months ago.

> And the most ugly thing was that the source files were not stored as
> text, you had to export them in order to get a java file to look at.

Who needs java files when one has a 'perfect' IDE. :-)

> I should try their new demo to see what they've changed...

The demo is 'old' as IBM is moving to eclipse and support for Visual Age 
will stop in the (near) future.

Regards,

Jac

-- 
 Jac Kersing            Technical Consultant   The-Box Development
 j.k...@th...                         http://www.the-box.com 

Re: [Embedlets-developer] visual designer/wiring tool

[Gregg G. W. <gr...@sk...>]

>Hi All,
>
>Has anyone (apart from me) ever worked with IBMs VisualAge for Java?  
>(Restricted version is available for download at IBM website) One of the
>great features of it was the ability to visualy design a swing (or awt)  
>user interface and visualy wire the events generated by one swing
>component to another one, or even better to wire events from beans to
>beans.
>
>First time I tried this I was sold. I haven't found another IDE that comes 
>even close. I think having something like this around would greatly 
>enhance acceptance of embedlets.

Yeah, I would have jump on that too, except they didn't have any way to 
interact with my source code management system, and I couldn't checkout 400+ 
files every time I wanted to work on the project... And the most ugly thing 
was that the source files were not stored as text, you had to export them in 
order to get a java file to look at.

I have't looked at it in ages though, and I understand that they did address 
several of these issues.  I did use it to build example applications that I 
linked together with the GUI.  It was a bit slow on my machine at that time 
(300mhz P-II)...

I should try their new demo to see what they've changed...

-----
gr...@cy...  (Cyte Technologies Inc)

Re: [Embedlets-developer] RE: Reply header

[Gregg G. W. <gr...@sk...>]

>AKKK!!!! I just did it again :(
>
>here is the repost...
>-----------------------------
>
>Well, your the list manager, so set it up how you like.,.. ;)
>
>IMO - its not what I intuitively expect because I'm reading the mail in a
>particular place, and when I hit reply, I "expect" it to go back there...
>intuitively I mean.

I have used MH for email since the mid 1980's.  I have used EXMH has my mail 
client since it was first created.  I can telnet/ssh to my mail machine from 
anywhere in the world and read my email and have instant access to all of 
it...  I am completely in tune with typing 'repl -cc all' to the shell when 
telnet'd in, and I am completely in tune with typing shift-R when using exmh.  
It just happens from habit.  I have replied to 'all' more than any other 
group. I find that I get a better 'default' to: list by doing that, and then 
editing it.  It's just habitual...

I am not literally saying "Just deal with in Brill", but am suggesting that 
everyone has to shape their world so that they feel comfortable.  MH lets me 
specify whether the default is '-cc to', '-cc cc', '-cc me' or '-cc all'.  I 
don't know much about the state of affairs in all these fancy pop-3 clients 
(mh lets me do 'inc --host' to do pop access).  So, I am not sure what to 
suggest to you or others that have problems with reply and reply all.  I can 
only suggest that this whole issue existed back in the mid 80's and was 
addressed, cussed and discussed at length.  The current mode of sourceforge is 
what was in use then, and has been in use largely everywhere that I've 
participated on mailing lists.  The exceptions being lists maintained by 
people who just appear to deal with mail differently, and who may not choose 
to have private conversations about list materials with the senders of 
personally interesting or controversial topics...

-----
gr...@cy...  (Cyte Technologies Inc)

[Embedlets-developer] visual designer/wiring tool

[Jac K. <j.k...@th...>]

Hi All,

Has anyone (apart from me) ever worked with IBMs VisualAge for Java?  
(Restricted version is available for download at IBM website) One of the
great features of it was the ability to visualy design a swing (or awt)  
user interface and visualy wire the events generated by one swing
component to another one, or even better to wire events from beans to
beans.

First time I tried this I was sold. I haven't found another IDE that comes 
even close. I think having something like this around would greatly 
enhance acceptance of embedlets.

Regards,

Jac

BTW. Of all the lists I'm currently receiving (over 20) this one takes 
most time to read due to the high volume of traffic on some days and the 
size of the messages. :-)

-- 
 Jac Kersing            Technical Consultant   The-Box Development
 j.k...@th...                         http://www.the-box.com 

Re: [Embedlets-developer] RE: Reply header

[Jac K. <j.k...@th...>]

On Mon, 27 Jan 2003, Ted Kosan wrote:

> Evidently when the reply automatically goes to the list people can more
> easily send a sensitive email to the whole list that was just meant for
> a single person.

Great default when a lot sensitive mail is being exchanged, however for an
open discussion group like this the other way around makes more sense to
me.

> What do people think?

Flip the switch please :-)

Regards,

Jac

-- 
 Jac Kersing            Technical Consultant   The-Box Development
 j.k...@th...                         http://www.the-box.com 

Re: [Embedlets-developer] Re: General event mechanism

[Gregg G. W. <gr...@sk...>]

>Like I keep saying... why does it have to be XML? there is no real advantage
>in this application. Should you want to interface XML for normalized
>transport to *external* applications, conversion would be a fairly simple
>task... so again, why must the "native" protocol use XML? What point to it
>except wasting memory, speed and bandwidth?

The spec is a onetime trabsported/installed, configuration file.  It is used 
to contruct the application, and/or configure its execution and that is the 
only time it is used.  If you want to transport binary data, fine.  If you 
want to GSM compress audio fine.  I am a proponent of simple, non-verbose 
information transmission.  We do our business in markets where margins are 
everything.  Anything that costs more per site is a problem for us....

>XML is best suited for static storage and transport of data between
>*dissimilar* applications/processes... in fact, that's what it was designed
>for.
>
>I feel fairly strongly that we need a far more efficient and small/fast
>protocol, which XML is not.

Computers were designed to target weapons, but they ended up being useful for 
other applications as well :-)  XML is infact great for neutralizing data 
representations and labeling and containerizing it.  The strict syntax, and 
the ability to use a DTD driven editor to control its content, also makes it 
good for configuration specification, where the configuration is complex and 
the user always does better when helped by a tool.  Rather than writing a new 
configuration management GUI for each application, why not just design a DTD, 
and let the user use their favorite XML editor so that you don't have to make 
that part of the cost of your software?  You also let those that design UI's 
good, compete at that, and you can compete with a lower cost in your market...
-----
gr...@cy...  (Cyte Technologies Inc)

Re: [Embedlets-developer] RE: Reply header

[Brill P. <bri...@ro...>]

AKKK!!!! I just did it again :(

here is the repost...
-----------------------------

Well, your the list manager, so set it up how you like.,.. ;)

IMO - its not what I intuitively expect because I'm reading the mail in a
particular place, and when I hit reply, I "expect" it to go back there...
intuitively I mean.

Anyway... it works ether way, but I keep sending mail for the list to
individuals! which means the poor buggers have to read my dribble twice when
I repost it ;)

- Brill Pappin
  Rogue Robotics
  www.roguerobotics.com

----- Original Message -----
From: "Ted Kosan" <tk...@ya...>
To: <emb...@li...>
Sent: Monday, January 27, 2003 6:46 AM
Subject: [Embedlets-developer] RE: Reply header


> James,
>
> > BTW - This replytoall and then edit out the author to reply to the list
is
> > confusing. Is this what we all decided was the prefered mechanism? I
would
> > prefer reply to go to the list..
> >
>
> I researched this and the reason that sourceforge (along with a number of
> internet communities) has one select 'reply to all' and then edit out the
> original poster is that it forces one to send a post to the whole list
only
> after consciously making an effort to do so.
>
> Evidently when the reply automatically goes to the list people can more
easily
> send a sensitive email to the whole list that was just meant for a single
> person.
>
> If most people want to change this I could do so and make it work like the
Cork
> list is set up but as it sits now we are using the sourceforge recommended
> default setting.
>
> What do people think?
>
> 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
>

Re: [Embedlets-developer] Re: General event mechanism

[Brill P. <bri...@ro...>]

Ok, this replying to the individual is annoying... I just posted back to an
individual a message intended for the list

this is a repost to the list where I logically expected it to go, having
received it from the list.

> My grand plan, would let you create a complete XML base spec of data
> packaging, poll scheduling, publish timing, extraction etc so that I could
FTP
> the XML to the outpost device and it would do the right thing.  I could
hand
> the same document to my broker and it would know how to extract the data,
and
> where to deliver it to...

Like I keep saying... why does it have to be XML? there is no real advantage
in this application. Should you want to interface XML for normalized
transport to *external* applications, conversion would be a fairly simple
task... so again, why must the "native" protocol use XML? What point to it
except wasting memory, speed and bandwidth?

XML is best suited for static storage and transport of data between
*dissimilar* applications/processes... in fact, that's what it was designed
for.

I feel fairly strongly that we need a far more efficient and small/fast
protocol, which XML is not.

- Brill Pappin
  Rogue Robotics
  www.roguerobotics.com

[Embedlets-developer] Re: General event mechanism

[Andrzej J. T. <an...@ch...>]

Gregg:

> In a sense, yes it is serialization :-)  But it's not 'native' so I tend
> to not call it Serialization...  Just terminology differences to try and
> not confuse folks, causing them to think I am using Serializable Objects.

You call it tomato....I call it tomatoe! ;-)

> In many environments, there are so many points to monitor, and the
> revenue from those sources is so small, that every opportunity must be
> taken to reduce per unit cost.  If a unit requires extra bandwidth that
> doubles the networking resources required (speed and/or bandwidth),
> then certain steps must be taken. XML over the wire is a limiting
> factor instead of an enabling factor in many such applications.  There
> must be a choice... 

We're in violent agreement I think....you should be able to switch out the 
protocols and encodings transparently.   I just don't think you should do this till 
you hit a situation where you absolutely have to is all.  In general, when 
building apps, optimization and performance tuning, if done too early, can 
waste a lot of effort for very little (or no) gain.  But the capability to do the 
tuning/optimization must be there of course.

> I am mainly concerned about data gathering issues, not general embedded
> Java applications on remote devices that may or may not provide
> information to the world...  So...

Well...that's a valid viewpoint, but I think Embedlets need to be a bit more 
generic and capable that just data gathering devices.  

> My grand plan, would let you create a complete XML base spec of data
> packaging, poll scheduling, publish timing, extraction etc so that I could
> FTP the XML to the outpost device and it would do the right thing.  I
> could hand the same document to my broker and it would know how to extract
> the data, and where to deliver it to...

Realistically, for a lot of devices, it would make sense to code generate the 
application from the XML and then send the app down to the embedded 
device....just for performance reasons on very limited devices.  But the 
concept is the same nonetheless.

In fact, once we write the container, and a generic, configurable "data 
monitoring" embedlet (or more likely a small collection of embedlets that co-
operate in performing the task....a monitoring embedlet, a packet encoding 
embedlet and a transport adapter embedlet), Outpost should be able to do 
exactly that, with just the XML config info changing from one implementation to 
another.

> >But above all else, a plug-n-play approach to transport protocols and
> >packaging is required, since then you can switch things around as you
> >need it (if you need it).
> 
> Yep Yep!

Might be best handled by creating protocol-specific transport adapter 
embedlets that listen to particular events and then send stuff out the back end.

I like the thought of the combo of the packaging embedlet coupled with a 
different one that does the transport.  That way the packaging is de-coupled 
from the transport for maximum flexibility.

Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com

Re: [Embedlets-developer] Re: General event mechanism

[Gregg G. W. <gr...@sk...>]

>> Thus, stuff sent between JVMs needs to be repackaged apon
>> exit and entry to any JVM. 
>
>That is just a form of serialization (I'm using the term more generically 
than as
>the used in the Java object serialization API).  You always have to 
>serialize/deserialize data for on-the-wire transport.

In a sense, yes it is serialization :-)  But it's not 'native' so I tend to 
not call it Serialization...  Just terminology differences to try and not 
confuse folks, causing them to think I am using Serializable Objects.

>XML is about the only standardized, neutral way to handling this.  It can be 
>verbose....but that can be mitigated pretty easily (use shorter tags), and 
>typically sending an event does not generate very big XML payloads, so in all 
>but the most constrained environments, I don't think it's worth using a 
>proprietary protocol instead of XML.

In many environments, there are so many points to monitor, and the revenue 
from those sources is so small, that every opportunity must be taken to reduce 
per unit cost.  If a unit requires extra bandwidth that doubles the networking 
resources required (speed and/or bandwidth), then certain steps must be taken. 
 XML over the wire is a limiting factor instead of an enabling factor in many 
such applications.  There must be a choice...

>Besides, if the application is architected correctly, then the transport 
>protocol/encoding would/should be de-coupled from the application, in which 
>case if you run into bandwidth issues with XML, then you just replace the 
>transport layer with something more efficient.

And this is what we have to account for.

>> Byte arrays are compact, but more difficult to
>> manage.  We, historically, have used byte arrays in our solutions.  We use
>> XML to describe the structure of the data, and have a DOM based parser
>> that builds an expression tree out of the document which is then executed
>> for field extraction.  Slightly more complex, but infinitely flexible
>> because we can inject user coded evaluators/extractors to get data out of
>> any container, byte array, or otherwise...
>
>Nice approach!  To use something similar for embedlets, it would probably be 
>better to read the XML and then code generate Java that would do the 
>construction/extraction of the binary data, just for performance reasons.  
This
>would not be hard to do.

An example of what we use in our product today is at: 

	http://www.cytetech.com/~gregg/weg.

Look at this with an XML enabled browser, there are XSL style sheets that will 
hide the gore of the XML...

I am mainly concerned about data gathering issues, not general embedded Java 
applications on remote devices that may or may not provide information to the 
world...  So...

My grand plan, would let you create a complete XML base spec of data 
packaging, poll scheduling, publish timing, extraction etc so that I could FTP 
the XML to the outpost device and it would do the right thing.  I could hand 
the same document to my broker and it would know how to extract the data, and 
where to deliver it to...

>But above all else, a plug-n-play approach to transport protocols and 
>packaging is required, since then you can switch things around as you need it 
>(if you need it).

Yep Yep!

-----
gr...@cy...  (Cyte Technologies Inc)

[Embedlets-developer] Re: Reply header

[Andrzej J. T. <an...@ch...>]

> What do people think?

Think?  We're supposed to be thinking on this list?  Doh!

Now why didn't I think of that?

As for the headers, I don't really care one way or another, since I'm used to 
checking the reply-to address....

Nice to see the list starting to heat up again!  Mind you, it was -34C last night 
and somewhere around -25C this morning at my place....so any heat 
whatsoever is a welcome thing!  The joys of living in the north country....

Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com

[Embedlets-developer] Re: Design Thoughts (reponses to Ted's points)

[Andrzej J. T. <an...@ch...>]

Ted sed:

> All the design documents are in OpenOffice 1.0's XML file
> formats so they can be managed by a CVS system very easily.

That's very cool.  I installed StarOffice a while back, but haven't used it much. 
This might be a good excuse to do so.

> Embedlet logic can be developed using:
> 
> 1)  Java.  

That's probably a given.... <grins>

> 2)  PICBASIC.  For people who are not skilled Java developers there is no
> reason why a PICBASIC interpreter Embedlet could not be created and then
> people who know how to program in PICBASIC can easily develop their own
> Embedlet logic.  If Embedlets are capable of being graphically wired
> together using a wiring tool then these people will not even necessarily
> be aware that they are using Java at all.

I think that anyone that can figure out how to use PICBASIC should be able to 
use Java in a simple scripting mode.  But maybe I am mistaken on that....and 
regardless, you are correct that an interpreting embedlet could be written quite 
easily.  Better still, would be a code generator that took PICBASIC and 
translated it into Java, which would then be compiled.  Better performance that 
way on limited devices.

> 3)  LADDER LOGIC.  If Embedlet logic can be developed in PICBASIC why not
> allow it to also be graphically developed using LADDER LOGIC?

It could...but I don't think that should be the initial focus of our efforts. Once we 
have a few Outpost/Embedlet containers running using Java, then we can see 
what makes sense in the way of additional language/scripting support.

> The deeper that I dig into developing a solution to the Elevator challenge
> the more I am convinced that Embedlets are capable of elegantly
> accommodating an extremely diverse set of needs.

Embedlets are just a container design for limited devices, with a full 
programming language included (Java in this case).  With that flexibility you 
can implement anything that is Turing Complete.  The question is not can 
we....but should we, and if so, when?

> most people seem to have forgotten that
> JavaBeans were originally designed as a general purpose software component
> technology capable of supporting a large software component market for
> people that wanted to graphically wire applications together.  Beyond
> this, with EJBs and the enterprise market taking off like it did there
> were little resources or desire to pursue the original JavaBeans vision.

I would add that there has not been any substantial market demand for such 
graphical programming/assembly tools.  On any platform (not just Java).  Even 
with COM components and VB assembly, the issue you come down to is that 
custom application logic has to be coded in a programming language (and I 
don't see that changing in the near term....Java/C/C++/Perl/Basic aren't going 
away for a long time).  And as soon as you have to write code, the benefits of 
switching to a graphical tool for part of your work lessens substantially.

> The new BeanBuilder tool is open source and I would like to use it as the
> foundation for the initial proof-of-concept Embedlet Wiring tool.

I have no issue with that.  So long as the GUI tool creates the underlying 
Embedlet XML config file that can be then pumped through the Embedlet 
configurator/builder.  But somehow I think this will be a philosophical sticking 
point....

> We are in complete agreement here.  The Embedlets themselves will often be
> very complex and so they will probably be developed in Java by skilled
> Java programmers.  The graphical wiring capabilities are just for allowing
> non-programmer application assemblers to assemble applications using
> standard software components (Embedlets).

If all you are doing is simple wiring, then having the GUI generate an XML 
Config file that specifies the "glue" is not that hard to do.

> I agree that the container could offer standard services but I think that
> the services should be pluggable so that if one wanted to put a minimal
> service Embedlet Container in a uVM it could be easily done.

Absolutely....as many services as possible need to be optional.  The ones that 
would be mandatory would include Event Management, Component Lifecycle 
Management and Scheduling (more on the scheduling issue later).  Optional 
ones could be: Logging, Management (JMX), and others.

> I think that we will need to discuss this point further.  I think that if
> a non-programmer application assembler is developing an Embedlet based
> application then they should be able to do so by directly wiring the
> application together using a graphic wiring tool (which is a technique
> that has been proven to work well by JavaStudio and the various versions
> of the BeanBuilder).

I think this wiring should be specified by an XML config file.  Which in turn 
could be generated by a graphical tool for those that are so inclined.

I'm still nervous about the graphical construction approach, since it has never 
succeeded in the marketplace, whereas XML-based configuration capability 
has.

> I do not see why we can not provide both mechanisms especially since they
> seem to be complementary.

There is no reason we can't do both....

> So far the experience I have had with developing a solution to the
> elevator problem indicates that quite complex applications can be
> assembled by graphically configuring components and wiring them together. 
> I hope to have my solution available for critiquing within 2 weeks so that
> we can see if I am missing something critical.

The XML Config specification, if it contains a comprehensive, standalone 
description of the config'ed app, would probably still be rather complex.  That 
is not a really big deal in my mind, since the XML would only be processed on 
a development workstation (eg. PC) and not on the embedded device itself.

> The route that the wiring tool is taking is to allow the application to be
> graphically wired together and then the application's complete object
> graph is saved using the LTP API and then also deserialized into the
> embedded system.  I have already successfully deserialized small
> applications into a TINI as a proof of concept (it worked well) and I
> think that this technique will work with the uVM too.

I prefer a code-generated approach (for the most constrained devices) and a 
dynamic config approach (for more capable ones).  My gut feel is that it will 
provide more flexibility and performance that way, rather than using serialized 
instances.  The bean assembly approach (with it's serialized persistence 
metaphor) works well in scenarios where you have fewer classes than 
object....that is, when you instantiate many objects of a particular class.  This 
is common with apps that are UI based, where you instantiate visible widgets 
like text edits, scroll bars, labels, etc.  I don't see much value to that approach 
when you there aren't as many objects and the classes do most of the work 
(as would be the case with embedlets).  The level of complexity is reduced 
substantially, since there are not that many objects to instantiate, and the 
server process can do that based on the config info (rather than re-consititute 
a serialized instance).

> I think that we should definitively prove that one Embedlet specification
> is incapable of spanning the full spectrum of target environments before
> falling back on multiple specifications.  I currently think that one
> specification will be sufficient.

I agree.  One spec.  But there may be many different container 
implementations based on that spec.  aJile chips have threads, so why not 
have a container that can leverage that?  uVM may not have threads, so a 
different container may be needed.

> I think that, just like with security, if the graphical wiring capability
> is not built in from day one that it can not be successfully be tacked on
> afterwards.  In order to accommodate graphic wiring, Embedlets simply need
> to permit their properties to be configured using setters and getters
> (achieved mostly through naming conventions) and they need to allow for
> the registering, unregistering and handling of events.  They should suffer
> no more than normal JavaBeans have by being able to be using in a graphic
> wiring tool.

The graphical tool could just as easily set the property values in the XML 
Config file rather than using bean-based introspection and the like.  So that's 
not a big issue.  I think we can also build a container where the actual 
embedlet code can avoid registration/unregistration for events by having that 
registration handled by the container on the components behalf (we might 
want a way to unregister dynamically, though I think this will not be needed 
much since embedlets will typically listen to a small number of events all the 
time, and that might be better handled with lifecycle events).  In any case, the 
simple cases should probably have such "plumbing" issues handled 
automatically based on an XML descriptor (as I had proposed), with a dynamic 
API available for the odd case that might be needed.

> With JAPL, Embedlets can handle all possible 'peripherals' from simple
> devices to the most complex backend system.  Again, this is shown in the
> following simple Embedlet application (notice that it is hooked up to a
> backend enterprise system):

I don't think JAPL is necessarily a good way to abstract communication to the 
host systems (a specialized embedlet might make more sense for that).  And 
having a standard API for device access is a good thing, but there are some 
scheduling issues if you are running in a container environment.

The focus of control of scheduling (and things like event management across 
multiple embedlets) is the Container.  So an embedlet should not grab the 
processor and keep it.  If the platform supports threads, then this is easy to 
implement (eg. PC's, aJile boards).  The problem is if you don't have threads.  
Then the embedlets need to use a co-operative processing approach where 
they relinquish control back to the container rather quickly...probably just 
responding to events as they get them.

What if an embedlet needs to regularly monitor a bit on a physical device?  
Sure JAPL lets you use a nice abstracted API to get the bit.  But without 
threads, how do you construct an Embedlet that can do periodic tests using 
the JAPL API call?  It can't just do a delay loop with a test, since then the 
container and other embedlets won't get any processor time.  One way is to 
have a PeriodicTimerEvent that Embedlets can subscribe to receive.  And 
each time it receives such a timer fired event it does one test using JAPL and 
then does something useful (maybe posting a different event).  This way you 
can have multiple embedlets running, without needing threads.

I don't think that it would make sense to embed these kinds of "polling" 
semantics into the JAPL API.  Rather, we could have some standard "off-the-
shelf" embedlets (and rather simple ones) that implement such semantics, 
basically talking to a device as required (whether polled, interrupt driven, 
threaded, etc.) and then translating the device data into a suitable 
EmbedletEvent that gets propagated further.  They would conceptually be 
"adapter" embedlets that translated between the hardware bits and the 
Embedlet Event paradigm.

> My primary goal is not to get enterprise developers more comfortable with
> embedded development.  My goal is to allow the semi-technical IT personnel
> which are present in most companies to be able to graphically wire
> together Embedded systems and attach them to backend enterprise systems
> with minimal help from the the enterprise developers.

This assumes that they won't need custom application logic on the embedded 
device.  That assumption might not hold very well in the real world, unless the 
scope of what embedlets do is rather reduced.

> My thought was that the $25/hour IT personnel should not have to bother
> the $100/hour enterprise personnel more often than was absolutely
> necessary in order to attach the eventually large number of embedded
> systems that companies will eventually need to be hooking to their
> enterprise systems.

If you are interfacing with enterprise systems, the enterprise guys will be 
involved.  No way they will allow anyone to plug just anything into the large 
back end systems.  Initially the end to end solution would have to be 
architected, which would involve everyone. Embedlets would be written.  After 
that, deploying more of the same types of controllers might be allowed, but 
initially I think it will involve everyone.  At best, the server side people will insist 
on massive integration testing.

> In my scheme, the enterprise developers are primarily used as a 'back
> door' method for marketing the Outpost idea to companies.  Even though
> some of them might catch the embedded systems bug, I think that most of
> them will not have the necessary background for interfacing embedded
> systems to their company's processes.

Maybe not....but they will be involved, and actively so, in any new 
implementation that interfaces with their back ends.  In fact, they would 
probably have to write new servlets (exposed as web services perhaps) to 
facilitate the integration, which means both side have to talk a lot.

> Without graphic wiring capabilities Embedlets are not usable by my pet
> target user base.

I don't think we should be targeting non-IT end-users for Embedlets.  The 
reason IT exists is to translate user requirements into a logical 
flow...something most users are not great at.  Graphical tools don't really help 
that problem.  And plant-level IT folks are definitely capable of using XML 
based configurations and writing some simple logic.

> I spent a significant amount of time digging into the dynamic proxy API
> and it will only run on JDK 1.3 and up APIs.  Numerous classes in the API
> were enhanced to accommodate dynamic proxies (like the serialization API)
> and almost no embedded Java system are going to have these capabilities in
> the near future.

I was thinking of PC's....there is a lot of applicability for using stripped down, 
hardened PC's on the plant floor as both controllers or concentrators (Level 1 
or 2 as was defined in the SoftPLC article).  A minimal PC with linux and a 
JVM would make a great Outpost platform for many applications.  And in that 
case, why not have a Container implementation that allows for more dynamic 
operations and leverage things like dynamic proxies, threads and more?

My only point is that the Outpost specifications should not preclude such 
container implementations for more capable platforms.  But it should not 
require such advanced capabilities either.

> Since all Embedlets that need to receive events implement one interface
> there is no need for dynamic event proxies.  

There may be value in allowing an embedlet to receive different events 
through different methods.  It potentially gets rid of long Select/Case chains in 
the Embedlet logic, letting the container do the "routing" for the embedlet.

> Simply have an Embedlet
> register itself as an event listener for a specific type of EmbedletEvent
> on any given target Embedlet and thats it. 

Better still, have the container register the embedlet as part of the initialization 
process, if the config says that the embedlet wants to receive certain event 
types.

> I read through your event mechanism description and, believe it or not, it
> is almost identical to the event mechanism that was developed for JavaOS. 
> I think the fact that you independently came up with an event mechanism
> that is very close to the event mechanism that the pricipal designer of
> Apple's PCI device driver architecture, Sun and IBM arrived at after years
> of effort is significant.

It's also very similar to best practices in the Messaging world (JMS) and event-
driven windowing systems (which is where it all began).  This stuff has a large 
body of "best practices" out there.

> Where our current approaches differ is 1) direct event registering
> vs.using an event broker and  

There would still be an event broker (the container itself) in either scenario.  
It's just that letting the container (rather than the component) handle the 
registration might have some benefits, per my earlier comments.

2) having multiple interfaces for
> registering event listeners on a event producer vs. having one generic
> event registration interface for all producers.

How about no interfaces (at least not mandatory ones) for the registration, and 
let the container handle that.

>  I am
> not sure how dynamic a typical embedded system needs to be.

As soon as you have more than one embedlet running, you get into the 
scheduling issues I mentioned.  Which implies the need for a Scheduler and 
Event Manager (broker)....which I see as the responsibility of the Container.

> I think that some more discussion on this topic and some experimenting
> would be sufficient to clarify these two issues for me.

Yup...

> Is there any chance that I could persuade you to obtain a copy of the
> JavaOS book (Inside the JavaOS Operating System, Saulpaugh and Mirho,
> Addison-Wesley, ISBN 0-201-18393-5, available from Amazon) so that we can
> discuss the merits of an event broker approach using a working and proven
> example as a starting point?

I don't think my schedule will allow it....and I don't think it's necessary.  Event 
and Message-based systems are something I know a lot about.

> From the research I have done on JavaBeans it appears to me that the two
> things that killed its potential for creating a large component market was
> 1) the lack of a robust method for long term persistence of object graphs
> and 2) an event mechanism that was not general enough to allow an
> extremely wide range of software components to be easily wired together. 
> Number 1 has already been solved and I think we have an excellent shot at
> solving number 2.

I think #2 will still take some time, and will likely build on the work in the Web Services area to some degree.  The difficulty in wiring a wide range of components is that it invariably requires some custom logic....which is easier to do in a programming language than in a graphical tool.  
> As for EJBs, it seems to me that doing enterprise Java development right
> is so complex that highly skilled Java programmers are absolutely needed
> in order to 'knit' everything together.  

Hence the need for us to keep the embedlet spec and related XML configs as 
simple as possible.  We have an advantage, since most embedded processors 
will not need the same scalability, security, transactional and flexibility 
characteristics that are needed on the enterprise end.

> If even the Java developers can
> not agree on fundamental things like whether Container Managed Persistence
> or Bean Managed Persistence is the best persistence mechanism to use then,
> to me, this is an indicator that EJBs are not yet mature enough to support
> non-programmer application assemblers.

That has nothing to do with component assembly....and everything to do with 
the inflexibility of CMP in real-world situations, versus complex O/R Mapping 
tools typically used for BMP.  The EJB spec is also fundamentally flawed in 
that it mixes together a number of requirements that are orthogonal to each 
other, such as security, transactionality, scalability and persistence.  Note that 
the first three are typically cross-cutting concerns, whereas persistence is 
more localized.

> The Embedlet space is looking like it is significantly simpler than the
> EJB space and the more I work on a solution to the elevator problem the
> more I am convinced that Embedlets have a real shot of being the first
> Java software component technology to create a large and successful
> component market.

The issue of granularity also works against widespread wiring of finer-grained 
components....and we haven't even resolved and deployed solutions to wiring 
of much coarser-grained services (though the web services community is 
working on that).  

Past history with software component markets would lead me to believe that 
we are a ways from that.  If such a market arises, great...but I don't think the 
creation of such a market should be our primary consideration.  

> Over the past few weeks JAPL has been developed to solve the device
> drivers problem.

Where can I get more info on the JAPL API?  Does it resolve the co-operative 
processing of multiple components issue (polling) problem (which I think it 
should not....that should probably be left to adapter Embedlet components 
rather than complicate the JAPL API).

> Could you draw up a model of the same application that uses an alternative
> to JAPL to solve the device driver problem?

It would look just like your diagram with the only exception being that I don't 
think the API should handle the host communications.  It should stick to being 
a VPL API definition only.  The point I am trying to clarify is where does the 
event scheduling happen, which is not specified in the diagram. I think it 
should be in the Sensor and Alarm Embedlets....using an approach similar to 
the "polling" example I mentioned above.

> What do you think about creating a 'Taramina' folder in the dev_docs
> directory of the CVS and placing your design work under version control?

Sure...when I have something ready, but I would rather we set up a generic 
"scratchpad" area for such musings, rather than tie the folders to specific 
names  Most of this is still in napkin diagrams or in my head right now.

> Together the JAPL specification and the Embedlets specification solve so
> many of the embedded space's current problems that, if they succeed at
> all, I think they will succeed in a very big way.  Thankfully, we are
> mostly responsible for developing the open specifications and providing
> open source reference implementations for them.  If these are done 'right'
> then the embedded space should just naturally build to these
> specifications just like the world built to the HTTP/HTML specifications
> when they were first released.

So the theory goes. ;-)

> 1) Embedlets provide platform-independent embedded logic at the binary
> level and  the Embedlet Container provides a virtual embedded system that
> will allow embedded applications to be completely shielded from the
> grueling platform churn and diversity that the embedded space is
> susceptible to.

The container should also provide some core services (and optional ones) so 
as to make embedlet code as simple as possible.

> 4) All the I/O chip manufactures make similar competing chips that are
> incompatible with each other.  For example, there are dozens of UARTS on
> the market and they all need unique device drivers.  Even embedded Java
> systems like the JStamp and TINI use proprietary classes for accessing
> things as simple as an 8 bit I/O port.  JAPL solves this problem for the
> application developer by coming up with one generic interface for each
> chip/peripheral type.  Now, all client code is compiled against one
> generic interface for each device type and then the task of developing a
> device driver which will allow any specific chip variant, like an 8250
> UART, to realize this interface is significantly reduced.  This represents
> the successful JDBC model brought into the embedded systems world.

Absolutely agree.

> 5) It allows embedded systems to be graphically wired together by
> non-programmer IT personnel.

I see this as a "nice to have" in the short term.

> 6) It enables the creation of a large software component market for the
> embedded space.

That is a risky target.  I would be happier just addressing the "pyramid" 
problem of getting an enterprise "wired" so that info flows from the shop floor 
right up to the enterprise systems (from embedded controllers to concentrators 
to server-side enterprise systems) as the initial primary goal.

> 7) Perhaps the most compelling story that these specifications have to
> offer is that they represent what I think may be the *first* wide scope,
> open source community and technology to be targeted toward the embedded
> space.  In an earlier post you were so right when you pointed out that
> almost all the endeavors to date in the embedded space have been extremely
> proprietary.

Yup....that is a key benefit of our approach.

> So, if JAPL and the Embedlet Container specification can actually succeed
> in providing the first open embedded systems platform and community that
> the whole embedded system's space can leverage, then I think it will be
> extremely successful.

It might.....but is still based on Java availability.  I think it's only now become 
feasible to deploy Java on smaller devices (aJile/Systronix leading the way 
here, and uVM coming soon hopefully), and so now we can leverage the 
ubiquity of Java down into the embedded space.

> I think the embedded space is ripe for the introduction of open source and
> I think we are in a position to significantly help with this.

For sure!


Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com

[Embedlets-developer] Re: General event mechanism

[Andrzej J. T. <an...@ch...>]

Gregg said:

> Events are completely separate from topics in my book...  Events carry
> data, topics tell you why the data is comming...

They are in my book too!  However, Event Types are equivalent to topics in 
many situations.  I should have been a bit clearer and specified that I was 
considering types and topics as more or less the same thing for an event 
management system.

> In the embedlet system, we can't make serialization and/or classloading a
> requirement.  

No argument there.  Though I would love to have dynamic classloading on 
aJile chip-based systems (like a JStamp).

> Thus, stuff sent between JVMs needs to be repackaged apon
> exit and entry to any JVM. 

That is just a form of serialization (I'm using the term more generically than as 
the used in the Java object serialization API).  You always have to 
serialize/deserialize data for on-the-wire transport.

> This is the fundamental need to meet protocol
> neutralization too.  Transport has to use a single, trivial to change
> representation.  XML is one, but is somewhat verbose for very small, low
> speed (cheap RF) networks.  

XML is about the only standardized, neutral way to handling this.  It can be 
verbose....but that can be mitigated pretty easily (use shorter tags), and 
typically sending an event does not generate very big XML payloads, so in all 
but the most constrained environments, I don't think it's worth using a 
proprietary protocol instead of XML.

Besides, if the application is architected correctly, then the transport 
protocol/encoding would/should be de-coupled from the application, in which 
case if you run into bandwidth issues with XML, then you just replace the 
transport layer with something more efficient.

> Byte arrays are compact, but more difficult to
> manage.  We, historically, have used byte arrays in our solutions.  We use
> XML to describe the structure of the data, and have a DOM based parser
> that builds an expression tree out of the document which is then executed
> for field extraction.  Slightly more complex, but infinitely flexible
> because we can inject user coded evaluators/extractors to get data out of
> any container, byte array, or otherwise...

Nice approach!  To use something similar for embedlets, it would probably be 
better to read the XML and then code generate Java that would do the 
construction/extraction of the binary data, just for performance reasons.  This 
would not be hard to do.

But above all else, a plug-n-play approach to transport protocols and 
packaging is required, since then you can switch things around as you need it 
(if you need it).


Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com

Re: [Embedlets-developer] Re: General event mechanism

[Gregg G. W. <gr...@sk...>]

>Gregg:
>
>> A vaching topic (String based) mechanism can be just as fast, as it can
>> assign an numeric value to a string based topic on the first use.  This
>> allows the numbers to be different between JVMs, but intra-JVM numbering
>> is consistent through the use of a factory.
>
>True, but an inheritence based approach for Events is simpler/faster and has 
>the added advantage that events could be sent out of the JVM as well.

In the embedlet system, we can't make serialization and/or classloading a 
requirement.  Thus, stuff sent between JVMs needs to be repackaged apon exit 
and entry to any JVM.  This is the fundamental need to meet protocol 
neutralization too.  Transport has to use a single, trivial to change 
representation.  XML is one, but is somewhat verbose for very small, low speed 
(cheap RF) networks.  Byte arrays are compact, but more difficult to manage.  
We, historically, have used byte arrays in our solutions.  We use XML to 
describe the structure of the data, and have a DOM based parser that builds an 
expression tree out of the document which is then executed for field 
extraction.  Slightly more complex, but infinitely flexible because we can 
inject user coded evaluators/extractors to get data out of any container, byte 
array, or otherwise...

-----
gr...@cy...  (Cyte Technologies Inc)

Re: [Embedlets-developer] Re: General event mechanism

[Gregg G. W. <gr...@sk...>]

>Gregg:
>
>> A vaching topic (String based) mechanism can be just as fast, as it can
>> assign an numeric value to a string based topic on the first use.  This
>> allows the numbers to be different between JVMs, but intra-JVM numbering
>> is consistent through the use of a factory.
>
>True, but an inheritence based approach for Events is simpler/faster and has 
>the added advantage that events could be sent out of the JVM as well.

Events are completely separate from topics in my book...  Events carry data, 
topics tell you why the data is comming...

-----
gr...@cy...  (Cyte Technologies Inc)

Re: [Embedlets-developer] RE: Reply header

[Gregg G. W. <gr...@sk...>]

>If most people want to change this I could do so and make it work like the 
Cork
>list is set up but as it sits now we are using the sourceforge recommended
>default setting.
>
>What do people think?

I like it the way it is!

-----
gr...@cy...  (Cyte Technologies Inc)

[Embedlets-developer] RE: Embedlet comments

[Andrzej J. T. <an...@ch...>]

James said:

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

We are...at least for the first implementations. ;-)

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

I was not implying that we reject commercial implementations.  
Heck...Chaeron might want to deliver a commercial Embedlet implementation 
for aJile processors at some point, as you might want to do for uVM. 

My only point is that the spec needs to be very robust, comprehensive and 
extensible.....hence my initial focus on high level architectural and design 
issues.  Building the containers won't be that tough.  Building the "constructor" 
will be a bit more difficult.

I'm spending some time on this primarily because it's an intriguing 
challenge....not for commercial gain.


Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com

[Embedlets-developer] RE: VBB and PLC's

[Andrzej J. T. <an...@ch...>]

James responds:

> Good to see you back in form Andrzej

I do try! <grins>

> 1) I totally agree that a XML backend is what we are after. And that any
> graphical viewer is just a visualiser for that XML. 

Great minds think alike.  Or is that "fools seldome differ"? ;-)

> I would like to keep the XML as simple as we can to begin and
> grow it upwards from there but if we can come up with the rich version up
> front then I am happy with this also. 

I believe it should be kept as simple as possible as well, but I do think that it 
will become rather complex pretty quickly so we might as well be prepared for 
that.

< as a group we seem better at theory and abstraction than
> hands on application. SO the thinking was to keep it simple as possible
> and move upwards.

Not quite....just haven't fleshed out enough of the abstraction to start pumping 
code yet.

> 2) I don't agree about the PLC as 'not important' are you kidding? It is
> probably the biggest field of embedded engineering out there!? However I
> think there has been a little confusion, I am not suggesting PLC's run
> embeddlets - actually I am suggesting the other way around, that embedlets
> can run PLC code. 

OK...I misunderstood your comment.  This makes sense. There is no reason 
that an Embedlet couldn't be written to implement Ladder Logic (or any other 
language for that matter, but given the constraints of embedded devices, I 
doubt that an embedded script language interpreter makes much sense).

> Specifically, I want a Ladder Logic ==> Embedlets.xml
> translator so that java devices running the embedlets framework can run
> PLC code. 

This won't work.  The embedlets XML file will likely be just a config file that 
specifies the context for the embedlet component, and it's linkages (which 
events it consumes/produces, what JAPL device it talks to and the like).  The 
"application logic" of the embedlet would be written in Java.  So what you 
would need is a code generator that can read PLC code and generate Java 
code inside an Embedlet context.

> 3) Yes, I am considering making VBB 'open source' It has alot to offer,
> openVBB is pretty much an implementation of the Outpost like Container. It
> uses a java backend with most of what we have been talking about with java
> objects created by reflection and an event driven SignalProducer/Consumer
> wiring model which can handle both synchronous(clocked) and
> aysnchronous(change-response) logic operators and has a XML-SVG component
> representation to boot.

I don't have a problem with building the Graphical Construction tool using 
different technology than Java.  VB can be useful for such stuff, though 
introducing a second technology (besides Java) makes the project more 
complex and harder to staff up.

> 4) No the standard and reference implementation will be open source. I
> think there will be many commercial implementations of the standard and
> don't have a problem with that. Not all TCP/IP stacks are opensource yet
> they implement a standard!

True enough...though I think that we will end up with "real" Outpost containers 
for different platforms that are all open source and useable in a production 
environment (not just RI's).

I have no problem with people building commercial implementations based on 
the Outpost/Embedlet standard.  But that might be a while...we'ld need to see 
some decent adoption of the standard and the initial containers before much 
commercial activity began.


Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com

Re: [Embedlets-developer] Re: General event mechanism

[Andrzej J. T. <an...@ch...>]

Gregg:

> A vaching topic (String based) mechanism can be just as fast, as it can
> assign an numeric value to a string based topic on the first use.  This
> allows the numbers to be different between JVMs, but intra-JVM numbering
> is consistent through the use of a factory.

True, but an inheritence based approach for Events is simpler/faster and has 
the added advantage that events could be sent out of the JVM as well.

Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com

Re: [Embedlets-developer] Re: General event mechanism

[Gregg G. W. <gr...@sk...>]

>What is a bit tricky is how to specify the Event Type in a globally unique 
way,
>since you don't want a developer to end up with a situation where the event 
>types were duplicated by two different embedlets/components, for different 
>purposes.  
>
>One way is to use integers as event types, with a single EmbedletEvent class, 
>which is handy since it's compact and processing them is quite efficient 
(rather
>than string compares), and you can use Select/case constructs in a single 
>receive() method to distinguish between different events.  But the issue there
>is how to ensure that different event types don't reuse the same integer 
>specifier.

A caching topic (String based) mechanism can be just as fast, as it can assign 
an numeric value to a string based topic on the first use.  This allows the 
numbers to be different between JVMs, but intra-JVM numbering is consistent 
through the use of a factory.

Here's an example of what I am talking about.

----------------------------

package org.wonderly.space;
 
import java.io.*;
import java.util.*;

/**
 *  This class represent topics in the Pub/Sub world.  These topics are
 *  cached through the use of a factory method.  This will help to reduce
 *  the overall numbers of strings and string tokenizers.  However, factory
 *  use and associated caching can create memory fragmentation if compaction
 *  is not present in GC.  As a general rule, the less garbage you
 *  create, the less you have to clean up :-)  So, in a pub/sub application,
 *  topics will be used everywhere, so caching of the topics makes good sense
 *  to reduce overall garbage collection.
 *
 *  Each topic is assigned a unique, but changes on each restart long integer
 *  id.  Comparing topics should still be done with .equals() though so that
 *  wild card matching can be performed so that 'app.data.<' will match
 *  'app.data.mydata'.
 *
 *  These objects are not serializable on purpose.  Serialize the string
 *  representation if you need to save something and use the factory
 *  method, <code>of(String)</code> to recreate the Topic on deserialization.
 *
 *  @author Gregg Wonderly
 */
public class Topic {
	public static final String SEPARATOR = ".";
	public static final String MATCH_CURRENT = "*";
	public static final String MATCH_REMAINING = "<";
	private String parts[];
	private String top;
	private transient long myUnique;
	static final long serialVersionUID = 8837984674953252299L;
	private static Hashtable topics = new Hashtable();
	private static long unique = (long)Math.random()*100203723217L;

	/**
	 *  Private constructor used to create each instance.
	 */
	private Topic(String s) {
		top = s;
		StringTokenizer tok = new StringTokenizer(s, ".");
		parts = new String[tok.countTokens()];
		int i = 0;
		while(tok.hasMoreTokens()) {
			parts[i++] = tok.nextToken();
		}
		myUnique = unique++;
	}

	/**
	 *  Topics are created by this factory method and cached to reduce memory
	 *  use
	 */
	public static synchronized Topic of(String s) {
		Topic t;
		if( (t = (Topic)topics.get(s)) != null ) {
			return t;
		}
		topics.put( s, t = new Topic( s ) );
		return t;
	}

	/**
	 *  Compares topics by making sure that each SEPARATOR
	 *  separated segment of the topic matches.  We don't keep
	 *  the original topic string around to perform equals() on.
	 */
	public boolean equals(Object obj) {
		if(!(obj instanceof Topic))
			return false;
		Topic topic = (Topic)obj;
		return topic.top.equals(top);    
	}

	/**
	 *  Returns the topic String representation
	 */
	public String toString()  {
		return top;
	}

	/**
	 *  Returns the hashCode() of the topic String
	 */
	public int hashCode() {
		return top.hashCode();
	}

	/**
	 *  Checks to see if a topic matches this topic.  Matching takes the presence
	 *  of MATCH_CURRENT and MATCH_REMAINING into account to create the right results
	 *  for partial matches
	 */
	public boolean matches(Topic topic) {
		// Simple test for same, exact, topics.
		if( topic == this || myUnique == topic.myUnique )
			return true;

		// Check the easy things...
		if(parts.length != topic.parts.length && 
			!parts[parts.length - 1].equals(MATCH_REMAINING) && 
			!topic.parts[parts.length - 1].equals(MATCH_REMAINING)) {
			return false;
		}
		
		// Launch a string comparison...
		for(int i = 0; i < parts.length; i++) {
			String s = parts[i];
			String s1 = topic.parts[i];

			// If we are at match rest, just match and stop
			if(s.equals(MATCH_REMAINING) || s1.equals(MATCH_REMAINING)) {
				return true;
			}

			// If segments don't match and there is not a wild-
			// card here, then stop with a failure.
			if(!s.equals(s1) && !s.equals(MATCH_CURRENT) && !s1.equals(MATCH_CURRENT)) {
				return false;
			}
		}

		return true;
	}
}

-----
gr...@cy...  (Cyte Technologies Inc)

[Embedlets-developer] RE: Reply header

[Ted K. <tk...@ya...>]

James,
 
> BTW - This replytoall and then edit out the author to reply to the list is
> confusing. Is this what we all decided was the prefered mechanism? I would
> prefer reply to go to the list..
> 

I researched this and the reason that sourceforge (along with a number of
internet communities) has one select 'reply to all' and then edit out the
original poster is that it forces one to send a post to the whole list only
after consciously making an effort to do so.

Evidently when the reply automatically goes to the list people can more easily
send a sensitive email to the whole list that was just meant for a single
person.

If most people want to change this I could do so and make it work like the Cork
list is set up but as it sits now we are using the sourceforge recommended
default setting.

What do people think?

Ted

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

[Embedlets-developer] Re: Embedlet comments

[Ted K. <tk...@ya...>]

James,

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


Together the JAPL specification and the Embedlets specification solve so many
of the embedded space's current problems that, if they succeed at all, I think
they will succeed in a very big way.  Thankfully, we are mostly responsible for
developing the open specifications and providing open source reference
implementations for them.  If these are done 'right' then the embedded space
should just naturally build to these specifications just like the world built
to the HTTP/HTML specifications when they were first released.

HTTP/HTML solved the world's 'Tower of Babel' problem and I think that JAPL and
Embedlets can do the same for the embedded space.


Here is a list of problems that these two specifications solve:

1) Embedlets provide platform-independent embedded logic at the binary level
and  the Embedlet Container provides a virtual embedded system that will allow
embedded applications to be completely shielded from the grueling platform
churn and diversity that the embedded space is susceptible to.

2) They allow the PIC community, along with all other microcontroller
communities, to easily bring their legacy code to the internet and make it
available to back end enterprise systems.  I think that this technology's
ability to bring together the embedded and enterprise communities is extremely
powerful.

3) They provide an excellent platform for building Greg's protocol neutralizers
which are critically needed in a fragmented space that consists of literally
thousands of industrial equipment protocols.

4) All the I/O chip manufactures make similar competing chips that are
incompatible with each other.  For example, there are dozens of UARTS on the
market and they all need unique device drivers.  Even embedded Java systems
like the JStamp and TINI use proprietary classes for accessing things as simple
as an 8 bit I/O port.  JAPL solves this problem for the application developer
by coming up with one generic interface for each chip/peripheral type.  Now,
all client code is compiled against one generic interface for each device type
and then the task of developing a device driver which will allow any specific
chip variant, like an 8250 UART, to realize this interface is significantly
reduced.  This represents the successful JDBC model brought into the embedded
systems world.

5) It allows embedded systems to be graphically wired together by
non-programmer IT personnel.

6) It enables the creation of a large software component market for the
embedded space.

7) Perhaps the most compelling story that these specifications have to offer is
that they represent what I think may be the *first* wide scope, open source
community and technology to be targeted toward the embedded space.  In an
earlier post you were so right when you pointed out that almost all the
endeavors to date in the embedded space have been extremely proprietary.

I have been thinking about that and one of the reason's that I came up with for
this problem is that embedded system software is so enmeshed with the platforms
they run on that open source efforts in this space did not make a lot of sense.

If one looks at the popular open source efforts to date they all seem to thrive
in environments that have common platforms.  For example, Linux provides the
standard platform on top of which a huge amount of open source software is
based and even Linux itself mostly sits on top of standardized 80X86 hardware. 
Of course, the Java platform provides the standardized base for Java's open
source projects and Windows provides another standardized base for open source.

So, if JAPL and the Embedlet Container specification can actually succeed in
providing the first open embedded systems platform and community that the whole
embedded system's space can leverage, then I think it will be extremely
successful.


I think we might be in the excellent position of a person who observes a wildly
successful product take off in Country A and then introduces this product into
Country B.  Most of the tough challenges were overcome in Country A and the
person simply takes all of the techniques that actually worked and uses them in
Country B.

I think the embedded space is ripe for the introduction of open source and I
think we are in a position to significantly help with this.


Ted


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

[Embedlets-developer] Re: Lots of posts...

[Ted K. <tk...@ya...>]

Andrzej,

>Some ideas are starting to gel on how to provide a flexible container 
> architecture, with optional JMX management features for Outpost.  But I have 
> a bit more work to do, and some prelim design before it'll be ready for 
> discussion.

What do you think about creating a 'Taramina' folder in the dev_docs directory
of the CVS and placing your design work under version control?

Again, I have decided to use OpenOffice for most of my design document needs
(text, drawings, spreadsheets, etc.) and so far its XML file formats are
working very well with the CVS.


Ted

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com