embedlets-developer — Outpost Embedlet container developer list

RE: [Embedlets-developer] Re: Cost analysis....

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

> Your enterprise costing numbers are ludicrious...obviously you have never
> managed (nor had budget authority) for a large enterprise-level
> development

You want me to do a full breakdown here on a list just to make a point?

Simply tried to make the point that unit costs are the dominant feature in
many (no not all) embedded applications and that java doesn't stack up well.

It was to make a point that you seem to have agreed with in the end so I'll
cop my simplistic view of the world on the chin ;-)

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




> -----Original Message-----
> From: emb...@li...
> [mailto:emb...@li...]On Behalf Of
> Andrzej Jan Taramina
> Sent: Sunday, February 02, 2003 9:48 AM
> To: emb...@li...
> Subject: [Embedlets-developer] Re: Cost analysis....
>
>
> James does a simplistic cost calculation:
>
> Your enterprise costing numbers are ludicrious...obviously you have never
> managed (nor had budget authority) for a large enterprise-level
> development
> team <grins>.  Cost of Project Management, Requirements Analysis,
> QA/Testing, Web Design, and Infrastructure/Tools/hardware to
> support all of
> these activities and the actual development would easily raise
> the cost into the
> million dollar category.  You can't just look at the coding costs.
>
> But no matter...the above is not really relevant to the embedlet
> situation.
>
> However, in the embedded world, I would expect that the QA/Testing
> requirements and costs would be even more substantial (hard to fix once
> you're burned the flash and distributed 100K devices into the field).
>
> > Java needs to compete head to head on cost to become a serious contender
> > in this market.
>
> Agreed to some degree.  But costs do have to include QA/Testing
> (typically
> much cheaper with Java than C/Asm), reliability (better with Java), speed
> (faster dev time with Java), ease/cost of finding qualified
> resources (again
> getting easier with Java developers, retraining costs would be
> much lower),
> and don't forget the most important part, which is a key idea of
> Outpost, the
> cost of integration with back end systems.
>
> You then also have to take into account that Java-based solutions
> might be
> more generic in nature, and thus you could potentially solve many
> disparate
> problems with only a single embedded hardware platform....which would
> reduce hardware engineering costs substantially.
>
> Also, think of the wide fan-out problem in corporations that wish
> to instrument
> their lower level processes to feed their enterprise systems (the
> Real-Time
> Enterprise that is being talked about in CIO-level publications
> these days, and
> the foundation idea that kicked of Embedlets in the first palce).
>  This is not the
> "classic" embedded market....and may not require 100K's of mass-produced
> devices...maybe just a few dozen...or a few hundred. In that
> scenario, the cost
> of the embedded device is much less of a factor, and the cost of
> development/integration becomes more significant.  Plus the
> familiarity with
> Java, Container-based systems, etc. will make corporations more
> comfortable
> with the embedded controller technology, since they would use Java-
> resources to develop everything from enterprise to embedded applications,
> with minimum retraining.
>
> Anyway, though your cost analysis has some validity, I think that
> the real
> market is not that clear or simplistic.  If it was, then
> MIDP/CLDC technology
> would not have become so prevalent so fast on consumer devices (like cell
> phones), since the same "costing" logic should apply there...but
> obviously has
> been superceded by larger concerns.
>
> > That is I think it is more important to ensure the minimal footprint of
> > the Embedlet spec is well conceived and that feature creep is kept to a
> > minimum to support our goals than is the thinking and resources required
> > for the wiring tool.
>
> I agree with this wholeheartedly!  The smaller the footprint and resource
> requirements (and prerequisite requirements) then the larger the
> potential
> market audience is.
>
> > These are by no means mutually exclusive goals, and I know you are very
> > focused on ensuring Embedlets will run on muvium and I want to support
> > whatever is needed to make that happen, special packages, serialisation,
> > whatever it takes..
>
> These goals are not mutually exclusive, but the balancing act
> will be delicate
> and non-trivial to get right.
>
> > I just want to ensure we all keep thinking lean!
>
> For sure, James!  Lean is one of my driving factors...as light as
> possible in
> fact.  But modular and extensible, so that more advanced (eg. less lean)
> features could be added for those platforms that can suppor them, without
> compromising the breadth of support for more constrained devices.
>
> 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
>
>

[Embedlets-developer] Re: Wiring tool versus Container Infrastructure: WE NEED BOTH!

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

Ted rants about his pet Graphic Wiring tool:

> Assertion 1: Without graphic assembly capabilities, Embedlets *don't* have
> a market. 

I don't agree...but DO agree that a Graphic Wiring tool would expand that 
market and would be a very valuable thing to have.

> Reason 1)  The only market that Embedlets *without* graphic wiring
> capabilities can be targeted toward is *Embedded* Java programmers.  So
> how many of us are there?  Lets check the numbers on the Embedded Java
> lists:
> 
> JStamp list - 333 members.
> JStik list - 64 members.
> TStamp_TStik list - 100 members.
> TINI list - estimated < 2000 members.

How about all the MIDP/CLDC/CDC etc Java programmers, who could easily 
use Embedlets to write embedded code?  There are more of those than in 
your total of all of the above.

How about Java programmers in general?  There are hundreds of thousands 
of them (more than C/C++ programmers according to surveys over a year old).  
They could also easily write embedded code given the right infrastructure and 
tools.

Lies, Damn Lies and Statistics, Ted.  You can shape the numbers to prove 
anything you want.  And I can do the same to refute your stats with my own.

> Extrapolating from these numbers one can (very generously) estimate that
> there are probably <10,000 Embedded Java programmers in the whole world at
> this point in time.

And a solid Container-based architecture, similar to Servlets/EJB's/etc, would 
raise that number into the hundreds of thousands that could quickly and easily 
learn to write embedded code using Outpost/Embedlets.

> In addition to the existing number of Embedded Java programmers being very
> small ,the rate of new programmers entering the Embedded Java group is
> equally small (see #3). 

Which is why creating an infrastructure that can be easily learned, with many 
off the shelf components would increase the number of developers capable of 
writing such applications by a few orders of magnitude.

> After looking at these extremely small numbers, one must ask “how do
> Embedlets enable this very small and slowly growing group to attain
> success with Embedded Java that they could not do with just regular
> Embedded Java?”  And the ruthless answer is “Not very much”.  TINIs have
> been around since 1999.  If Embedded Java was going to succeed in the
> marketplace using conventional marketing techniques, then TINI would have
> been a commercial success by now.  To date it has not been a commercial
> success.

Agreed.
 
> The primary reason for this is that Enterprise Java developers have no
> where near the background needed to successfully deal with the Embedded
> Space and they never will.

I disagree. I believe that a properly designed Outpost Container and Embedlet 
solution will be VERY familiar to the Enterprise Java folks, and make it easy 
for them to write embedded applications.

> 2) Trying to market Embedlets as a programming technology to primarily
> enterprise developers (including enterprise Java developers) is a flawed
> strategy that will fail.  

I'm not convinced that it is flawed....but obviously having a facility that allows 
non-programmer types to create simple (emphasis on the simple) embedded 
applications would be very beneficial to increasing the size of this market.  And 
hence a Graphic Wiring tool is very valuable to have.  

But it has to be built on a well architected, slim, fast base that provides the 
power and flexibility for developers to write complex embedlets, for if they can't 
create packaged, reuseable embedlets your whole argument breaks down.

Chicken and egg syndrome Ted. Your argument holds only if there is a large 
selection of pre-built embedlets to choose from.  But developers will not write 
such, unless the tools, infrastructure and capability to do such exists and is 
familiar enough and easy enough to co-opt the general Java developer 
community into being able to create components (embedlets) with minimal 
training.  And then there will always be applications that require custom logic, 
where the problems cannot be solved with off-the-shelf components.....so the 
Outpost platform has to be able to handle these situations as well.

We cannot have just a simple solution that makes more complex applications 
impossible (eg. a Graphical Tool without the underlying development 
infrastructure).  Obviously, the reverse of having powerful/flexible dev tools will 
not help as much if you can't handle the simple cases quickly, easily and 
cheaply.

However, I do believe that with an appropriate underlying architecture, we can 
have our cake and eat it too, by supplying a graphical wiring tool that sits on 
top of a modular, lightweight, powerful and flexible container framework.

What capabilities do Embedlets offer an
> Enterprise Java developer that normal Embedded Java does not offer them?

One could pose the same question regarding servlet containers versus using 
straight Java code.  The key is to simplify the application development to focus 
primarily on the business rules/needs rather than on plumbing and 
housekeeping.  That is why container architectures have become so popular.
 
> Answer: “Not much”.  Again, TINIs have been around for over 3 years now
> and they are very easy to attach to enterprise systems.  

Not they're not....you have to home-roll almost all the code to do so.  That is 
playing with plumbing rather than focusing on business requirements.  And 
you have to become an expert in the platform at hand, Tini's in your example.  
That is not productive.  The whole Outpost effort, from standardizing device 
drivers using JAPL, to reusable embedlets to pluggable protocol/transport 
gateways is to reduce the learning curve and promote both code and 
knowledge reuse.

> If Enterprise
> Java developers were going to take an interest in Embedded Java they would
> have already done so already with TINIs.  

I disagree...primarily because I don't think that most corporations have had a 
requirement for this level of top to bottom integration with 
monitoring/metrics/control that goes from the lowest manufacturing/distribution 
level up to the enterprise planning systems.  I have only started to see 
literature discussing the "Real Time Enterprise" (which will drive the need for 
such top to bottom integration) very recently, and I predict that this evolution in 
corporate thinking will drive increasing interest in such instrumentation 
capability.  That coupled with the first standardized integration technology 
(Web Services, using XML/SOAP) puts us at a very unique point in time, 
where an Embedlet solution might be able to leverage increased market share 
and attention.

> Embedlets without Graphic Wiring
> capabilities do not bring anything significant to the table that normal
> Embedded Java does not already offer.

I disagree, Ted, for all the reasons I have tried to outline above.  Sure...graphic 
wiring will be very useful, and I think we should build it (and build the 
underlying container architecture to support it), but I believe the confluence of 
business needs ( the emerging concept of the "Real Time Enterprise), 
common integration standards (web services), the availability of Java-based 
embedded systems, and the widespread adoption of container-based and 
java-based solutions will provide a lot of significant benefit just from the 
Embedlet/Outpost container itself, with Graphical Wiring adding a lot of icing 
on top of that benefit.

> Every piece of my input into the brainstorming process has centered around
> the goal of finding markets for embedded Java through allowing
> *non-programmers* (this is where 90% of the market is) to construct useful
> embedded system solutions using graphic embedded component assembly
> techniques.

This has never worked very well.  Programming is the "logical" expression of 
business rules and requirements.  Most non-programmers (except for trivially 
simple applications) have trouble thinking that logically.  Which means that for 
"real world" applications, not only do we need a tool to handle the simple stuff 
(graphical wiring)...but also the underlying infrastructure to allow professional 
developers to create much more complex applications that will be beyond the 
"logical cognitive" abilities of many non-programmers.  

We also need a solid platform for the development of Embedlet components 
(and JAPL device drivers, protocol/transport adapters, etc.) themselves, since 
the utility of a Graphical Wiring tool will be directly proportional to the 
availability of pre-built embedlets, as I had noted above.

We need BOTH Ted!  No-one is arguing against a Graphical Tool...I think it's a 
wonderful idea, that will drive much value.  But it will be useless without the 
right infrastructure and architecture under the covers.

> I have consistently stated that my “most likely *initial* target market
> for graphically wired Embedlets” were the legion of non-programmer IT
> support personnel who are present in all medium and large size companies. 

Great....give them a graphical tool with hardly any components to wire!  This 
group will never be able to create enough components to make that "initial 
target market" viable.  We also have to create a large community of 
component (embedlet) developers that can feed the pre-built components to 
this market.  And there is a huge experience base of such developers already 
that it makes sense to try and co-opt to the task.....Enterprise Java developers 
that know how to develop components for container-based systems.  It would 
be suicidal to not address this.

> The enterprise Java programmers were primarily a back door strategy for
> marketing graphically wired embedded systems to these IT personnel.  

See above. Chicken and egg syndrome Ted!  Who's going to produce all these 
great embedlet components that the naïve users will be able to wire?

> To say that Embedlets are only *for* solving problems in the enterprise
> space is just as suspect as Sun stating that Java was only *for* solving
> problems in the Embedded Space in the early 1990s.  Thinking about a
> technology in terms of what it is *for* is an extremely dangerous and
> limiting mindset to have.  A much better way to think about any given
> technology is in terms of what it can *do*.  Show any given group what a
> technology can *do* and they will figure out all by themselves what to use
> it *for* in their respective domains.  The best chance that Embedlets have
> of succeeding is for us to show as many diverse groups as possible what
> Embedlets can *do* and let them take it from there. (shirky.com).

You still need to pick a business problem and then provide a solution.  That is 
the surest way to success.  What it's "for" and what it "does" is irrelevant in it's 
impact and attention-getting capability when compared to "what problem does 
it solve".  That being said, I do agree with your comment above...

> 3) The size of the Embedded Java programmer group is very small, it is
> growing at a snails pace and so it is going to be small for a very long
> time.

See above comments.  I think I've addressed this.

> So, after working extremely hard for years to increase the size of the
> Embedded Java developer pool I can confidently state that it is going to
> happen *very* slowly and it is going to be an uphill battle every
> centimeter of the way.  I now know the reasons for this but we do not need
> to go into them here.

One of the goals of Embedlets was to break through this ennui, and provide a 
different (yet very familiar and proven) paradigm, to try and increase this pool 
substantially.  An embedded container!  This leverages prior art and known 
best practices, and has a great chance of succeeding.

> To summarize, Servlets, EJBs, JavaBeans... these technologies are wildly
> successful because the pool of developers that use them is in the
> *millions*. 

Um....Ted....the first two are wildly successful...but JavaBeans have never 
really taken off.  Sorry...but that is the reality of the market.  Sure, JavaBeans 
are useful (value objects, etc), but there are virtually no applications based 
solely on JavaBeans....almost all such apps are based on 
Container/Component architectures.

> Embedlets without graphic wiring capabilities are going to
> *fail without question* due to the simple fact that the Embedded Java
> developer pool is estimated to be < 10,000 and it is growing very slowly. 
> Almost anything marketed to a target market that is this small will very
> likely fail.

For all the prior reasons, I vehemently disagree.  I think embedlets could 
succeed without a graphical wiring tool.  However, I think it would be EVEN 
BETTER if we had such a tool, along with a good container 
implementation/standards.

Why the big rant trying to convince us that a Graphical Tool would be useful 
and beneficial.  I think we all agree with that...but it's not a sufficient condition, 
in and of itself, to guarantee the success of Outpost.  We need the underlying 
infrastructure.

And like I said, I really believe we can do both!

> So, Embedlets are 
> 
> - A Camelot 'round table' that allows diverse technologies and communities
> to be brought together for a common purpose.
> 
> - An airport terminal that allows data from multiple sources to be routed
> to multiple destinations.
> 
> - A United Nations which allows different languages using diverse
> protocols to work together to solve mutual problems.
> 
> - A benevolent Borg which accommodates and assimilates wildly diverse
> technologies into a collective that can leverage the laws of synergy.

Cute but so general as to be virtually useless. ;-)

Can we talk about HOW we deliver all of the above....in a useable form for 
both simple AND complex applications....for embedded application 
development AND embedlet component creation?  We need to address all of 
these if we are to succeed.

> The best chance that Embedlets have to fulfill this roll is by providing a
> way for extremely diverse market segments to be able to easily use them
> for solving their domain specific problems.  Currently, the most promising
> technology we have for enabling this is graphic assembly of software
> components (Embedlets). 

That is just ONE component of what a successful solution needs.  A good 
one...a useful one...but not sufficient in and of itself.

> Here are some low hanging fruit markets that graphic assembly Embedlets
> has access to:
> 
> - PIC programmers (huge group of non-Java developers).
> - 8051 programmers (huge group non-Java developers).
> - AVR programmers (huge group of non-Java developers).
> - PLC programmers (huge group of non-Java developers).

Who could all learn Java extremely quickly, at least enough to write code for a 
well designed Outpost Container architecture. To go from C/C++ to Java is not 
that hard for most programmers, especially if you have the plumbing already 
handled.  And who is going to write the intial embedlets, device drivers and 
communications adapters for all these platforms?  You're not going to wire 
those at first....

> - Non-Programmer IT personnel (millions of members).

Most of whom can't think logically enough to create applications, regardless of 
tool used....at least not for apps that are beyond trivially simple.

> - Lego Mindstorms programmers (huge group of non-Java programmers).
> - etc.

This would be a great group to co-opt...and get over to use Outpost and 
Embedlets.  I would bet that after doing some simple apps (using the Outpost 
Graphical Wiring tool), they would start to experiment with creating their own 
embedlet components, custom device drivers, etc.  But we have to be careful 
that we do not inadvertently label Outpost/Embedlets as "toy technology".

> just simply are not enough of us to directly service this combined market
> by directly programming these solutions ourselves (again, anyone who
> thinks they can refute this claim will need to show their numbers).

And there are not enough of us (on this list) that can create enough 
components to service this combined market.  WE NEED BOTH!

> As for the assertion that graphic assembly of applications does not work,
> the large Lego Mindstorms user base easily refutes this claim.  It
> obviously *does* work and is quite *successful* even when allowing for the
> fact that there is still much room for improvement in this area.

And as someone pointed out, this works well for simple apps....but soon the 
user discovers that they hit a wall (sooner than you think, which is why we 
don't all program using graphical metaphors yet).  And what do they do?  They 
dig in and start writing code!  We need to provide a solid foundation so that 
when a user has requirements that cannot be met with a wiring tool and 
existing components, they can easily develop their own.

> In conclusion.  I absolutely agree that a well architected Embedlet
> specification is extremely important to the Embedlets effort.  

Whew.....one would never guess from your rant above.

> I also
> maintain, however, that giving Embedlets state-of-the-art graphic wiring
> capabilities, and then marketing these capabilities to any and all markets
> that could potentially use them, is *equally* as important for Embedlets
> to succeed.

I don't buy the "equally", but such a comparison is silly anyway.  Who cares.  A 
graphical tool WOULD be very useful and would expand the potential market, 
and then lead to a larger pool of embedlet component developers (as they 
evolved past the easy stuff).

So let's build such a graphical tool....on top of the best Embedlet Container 
architecture known to man!

And along those lines....stay tuned for the imminent posting of an 
"Outpost/Embedlets Architecture Discussion Document" that is intended to 
foster discussion of an architectural solution that will allow us to do both!



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

[Embedlets-developer] Re: Cost analysis....

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

James does a simplistic cost calculation:

Your enterprise costing numbers are ludicrious...obviously you have never 
managed (nor had budget authority) for a large enterprise-level development 
team <grins>.  Cost of Project Management, Requirements Analysis, 
QA/Testing, Web Design, and Infrastructure/Tools/hardware to support all of 
these activities and the actual development would easily raise the cost into the 
million dollar category.  You can't just look at the coding costs.

But no matter...the above is not really relevant to the embedlet situation.

However, in the embedded world, I would expect that the QA/Testing 
requirements and costs would be even more substantial (hard to fix once 
you're burned the flash and distributed 100K devices into the field). 

> Java needs to compete head to head on cost to become a serious contender
> in this market.

Agreed to some degree.  But costs do have to include QA/Testing (typically 
much cheaper with Java than C/Asm), reliability (better with Java), speed 
(faster dev time with Java), ease/cost of finding qualified resources (again 
getting easier with Java developers, retraining costs would be much lower), 
and don't forget the most important part, which is a key idea of Outpost, the 
cost of integration with back end systems.

You then also have to take into account that Java-based solutions might be 
more generic in nature, and thus you could potentially solve many disparate 
problems with only a single embedded hardware platform....which would 
reduce hardware engineering costs substantially.

Also, think of the wide fan-out problem in corporations that wish to instrument 
their lower level processes to feed their enterprise systems (the Real-Time 
Enterprise that is being talked about in CIO-level publications these days, and 
the foundation idea that kicked of Embedlets in the first palce).  This is not the 
"classic" embedded market....and may not require 100K's of mass-produced 
devices...maybe just a few dozen...or a few hundred. In that scenario, the cost 
of the embedded device is much less of a factor, and the cost of 
development/integration becomes more significant.  Plus the familiarity with 
Java, Container-based systems, etc. will make corporations more comfortable 
with the embedded controller technology, since they would use Java-
resources to develop everything from enterprise to embedded applications, 
with minimum retraining.

Anyway, though your cost analysis has some validity, I think that the real 
market is not that clear or simplistic.  If it was, then MIDP/CLDC technology 
would not have become so prevalent so fast on consumer devices (like cell 
phones), since the same "costing" logic should apply there...but obviously has 
been superceded by larger concerns.

> That is I think it is more important to ensure the minimal footprint of
> the Embedlet spec is well conceived and that feature creep is kept to a
> minimum to support our goals than is the thinking and resources required
> for the wiring tool.

I agree with this wholeheartedly!  The smaller the footprint and resource 
requirements (and prerequisite requirements) then the larger the potential 
market audience is.

> These are by no means mutually exclusive goals, and I know you are very
> focused on ensuring Embedlets will run on muvium and I want to support
> whatever is needed to make that happen, special packages, serialisation,
> whatever it takes..

These goals are not mutually exclusive, but the balancing act will be delicate 
and non-trivial to get right.

> I just want to ensure we all keep thinking lean!

For sure, James!  Lean is one of my driving factors...as light as possible in 
fact.  But modular and extensible, so that more advanced (eg. less lean) 
features could be added for those platforms that can suppor them, without 
compromising the breadth of support for more constrained devices.

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

Re: [Embedlets-developer] Re: OpenOffice

[Nicola K. B. <nic...@ap...>]

Jac Kersing wrote:
> On Wed, 29 Jan 2003, Brill Pappin wrote:
> 
> 
>>>How about using DocBook? Still XML but everyone would be able to use their
>>>own 'pet' editor. And using the right tools it can be published in at
>>>least HTML, PDF, RTF.
> 
> 
>>Hey, looks interesting... I'd be into that I think... do you have some
>>preferred apps we can evaluate?
> 
> 
> Take a look at XML Editor and FO Convertor at www.xmlmind.com. To learn 
> more www.docbook.org, it has the "Complete reference" on-line, (and the 
> docbook sources of this O'Reilly book as well)

Take a look at this too.
http://xml.apache.org/forrest/

It can now use plain html too or wiki syntax.
It renders svg to png too, makes pdfs and is completely skinnable.

Ok, it's a shameless plug, I'm a developer there ;-P

-- 
Nicola Ken Barozzi                   nic...@ap...
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------

Re: [Embedlets-developer] Re: OpenOffice

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

On Wed, 29 Jan 2003, Brill Pappin wrote:

> > How about using DocBook? Still XML but everyone would be able to use their
> > own 'pet' editor. And using the right tools it can be published in at
> > least HTML, PDF, RTF.

> Hey, looks interesting... I'd be into that I think... do you have some
> preferred apps we can evaluate?

Take a look at XML Editor and FO Convertor at www.xmlmind.com. To learn 
more www.docbook.org, it has the "Complete reference" on-line, (and the 
docbook sources of this O'Reilly book as well)

Regards,

Jac

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

[Embedlets-developer] Re: Embedlets-developer digest, Vol 1 #31 - 7 msgs

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

> Point taken.  My main idea was to indicate that we were moving out of the
> open-ended brainstorming stage and into a getting-down-to-work stage.

I think there is a lot of brainstorming still to be done....it will just naturally 
evolved into more detailed areas rather than more sweeping issues is all.  Why 
artificially "shut down" the brainstorming?

> If development is not a good word to use here then what is a better way to
> describe this phase?

I'm not sure it's a "phase"....it implies we left the other one behind....let's forget 
the labels and just press onwards.

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

[Embedlets-developer] Re: Marketing

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

Chris suggests:

> This brings up another point in that early visibility and buyin by some of
> the big players (Dallas, AJile, Systronix, Intel, Lego) in this field
> should be one of the goals of this project if we expect it to gain any
> foothold. Anyone want to put on their marketing hat?

Sure....I have some extensive experiece in this area.  But I would rather wait 
till we have something more concrete to market before firing up such a 
campaign.

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

[Embedlets-developer] RE: Wiring Tool, Legos, PLCs, PICs, etc.

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

>The primary reason for this is that Enterprise Java 
>developers have no where near the background needed 
>to successfully deal with the Embedded Space and they 
>never will.

Opps!  This paragraph should have been placed immediately below the paragraph
that starts with

>2) Trying to market Embedlets [snip]

and not immediately above it.


Ted

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

[Embedlets-developer] Wiring Tool, Legos, PLCs, PICs, etc.

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

Assertion 1: Without graphic assembly capabilities, Embedlets *don't* have a
market. 

Assertion 2: With graphic assembly capabilities, Embedlets have access to a
significant number of huge markets.

I can amply support both of these assertions.


The premise that Embedlets alone (without state-of-the-art graphic assembly
capabilities) have a reasonable chance for success, can easily be proven to be
*false*.  Here are the reasons for this.

Reason 1)  The only market that Embedlets *without* graphic wiring capabilities
can be targeted toward is *Embedded* Java programmers.  So how many of us are
there?  Lets check the numbers on the Embedded Java lists:

JStamp list - 333 members.
JStik list - 64 members.
TStamp_TStik list - 100 members.
TINI list - estimated < 2000 members.

Extrapolating from these numbers one can (very generously) estimate that there
are probably <10,000 Embedded Java programmers in the whole world at this point
in time.

In addition to the existing number of Embedded Java programmers being very
small ,the rate of new programmers entering the Embedded Java group is equally
small (see #3). 

After looking at these extremely small numbers, one must ask “how do Embedlets
enable this very small and slowly growing group to attain success with Embedded
Java that they could not do with just regular Embedded Java?”  And the ruthless
answer is “Not very much”.  TINIs have been around since 1999.  If Embedded
Java was going to succeed in the marketplace using conventional marketing
techniques, then TINI would have been a commercial success by now.  To date it
has not been a commercial success.

The primary reason for this is that Enterprise Java developers have no where
near the background needed to successfully deal with the Embedded Space and
they never will.



2) Trying to market Embedlets as a programming technology to primarily
enterprise developers (including enterprise Java developers) is a flawed
strategy that will fail.  What capabilities do Embedlets offer an Enterprise
Java developer that normal Embedded Java does not offer them?  Answer: “Not
much”.  Again, TINIs have been around for over 3 years now and they are very
easy to attach to enterprise systems.  If Enterprise Java developers were going
to take an interest in Embedded Java they would have already done so already
with TINIs.  Embedlets without Graphic Wiring capabilities do not bring
anything significant to the table that normal Embedded Java does not already
offer.

Every piece of my input into the brainstorming process has centered around the
goal of finding markets for embedded Java through allowing *non-programmers*
(this is where 90% of the market is) to construct useful embedded system
solutions using graphic embedded component assembly techniques.

I have consistently stated that my “most likely *initial* target market for
graphically wired Embedlets” were the legion of non-programmer IT support
personnel who are present in all medium and large size companies.  The
enterprise Java programmers were primarily a back door strategy for marketing
graphically wired embedded systems to these IT personnel.  

To say that Embedlets are only *for* solving problems in the enterprise space
is just as suspect as Sun stating that Java was only *for* solving problems in
the Embedded Space in the early 1990s.  Thinking about a technology in terms of
what it is *for* is an extremely dangerous and limiting mindset to have.  A
much better way to think about any given technology is in terms of what it can
*do*.  Show any given group what a technology can *do* and they will figure out
all by themselves what to use it *for* in their respective domains.  The best
chance that Embedlets have of succeeding is for us to show as many diverse
groups as possible what Embedlets can *do* and let them take it from there.
(shirky.com).



3) The size of the Embedded Java programmer group is very small, it is growing
at a snails pace and so it is going to be small for a very long time.

This I can attest to from direct experience.  When TINI cam out in 1999 I put
together a free online Java/1-Wire/TINI class for it which lasted 12 weeks. 
Over 400 people took this course and I followed it up with a free online
Java/iTV course which had 600 people sign up for it (javadevices.org/dtcourse).
 I am currently in the process of putting together a free Java/TINI/TStik
course for the new Systronix TStik and a free Java/uVM course for the new PIC
based muvium (muvium.com).  

Beyond this I gave a Java/TINI BOF session at JavaOne last year and I put
together a compelling proposal to OReilly for an Embedded Java Beginner's book
(which they utterly rejected on the grounds that Embedded Java was a
non-existent market).  I was also part of a team that was a finalist in last
year's Visa Blue SmartCard programming contest and after this I submitted a
proposal to teach a free Java/SmartCard class to Gemplus users.

So, after working extremely hard for years to increase the size of the Embedded
Java developer pool I can confidently state that it is going to happen *very*
slowly and it is going to be an uphill battle every centimeter of the way.  I
now know the reasons for this but we do not need to go into them here.

To summarize, Servlets, EJBs, JavaBeans... these technologies are wildly
successful because the pool of developers that use them is in the *millions*. 
Embedlets without graphic wiring capabilities are going to *fail without
question* due to the simple fact that the Embedded Java developer pool is
estimated to be < 10,000 and it is growing very slowly.  Almost anything
marketed to a target market that is this small will very likely fail.

Refute this conclusion if you can but you better have evidence to back up your
position.



ARE THERE MARKETS FOR EMBEDDED JAVA?

Yes!  Lots of them and they are huge!  But the only way Embedded Java is going
to gain access to these markets is by not requiring them to learn how to
program in Embedded Java.  At this point in time the best way we have to
realize this is by giving Embedlets state-of-the-art graphic wiring
capabilities.

To me, the most important thing I have learned from all the brainstorming we
have done on the Embedlets idea is that *Embedded Java's primary strength is
that it is the best technology in the world for the task of “protocol
neutralization”* (which was Gregg's insight).  Embedlets represent the best
technology we could think of to capitalize on this strength.

So, Embedlets are 

- A Camelot 'round table' that allows diverse technologies and communities to
be brought together for a common purpose.

- An airport terminal that allows data from multiple sources to be routed to
multiple destinations.

- A United Nations which allows different languages using diverse protocols to
work together to solve mutual problems.

- A benevolent Borg which accommodates and assimilates wildly diverse
technologies into a collective that can leverage the laws of synergy.


The best chance that Embedlets have to fulfill this roll is by providing a way
for extremely diverse market segments to be able to easily use them for solving
their domain specific problems.  Currently, the most promising technology we
have for enabling this is graphic assembly of software components (Embedlets). 



Here are some low hanging fruit markets that graphic assembly Embedlets has
access to:

- PIC programmers (huge group of non-Java developers).
- 8051 programmers (huge group non-Java developers).
- AVR programmers (huge group of non-Java developers).
- PLC programmers (huge group of non-Java developers).
- Non-Programmer IT personnel (millions of members).
- Lego Mindstorms programmers (huge group of non-Java programmers).
- etc.

The only way I can see that the small number of Embedded Java programmers can
possibly support such an enormous combined market is by developing reusable
Embedlet components that this large group can use to graphically wire together
their own solutions to their respective problems.  There just simply are not
enough of us to directly service this combined market by directly programming
these solutions ourselves (again, anyone who thinks they can refute this claim
will need to show their numbers).


As for the assertion that graphic assembly of applications does not work, the
large Lego Mindstorms user base easily refutes this claim.  It obviously *does*
work and is quite *successful* even when allowing for the fact that there is
still much room for improvement in this area.


In conclusion.  I absolutely agree that a well architected Embedlet
specification is extremely important to the Embedlets effort.  I also maintain,
however, that giving Embedlets state-of-the-art graphic wiring capabilities,
and then marketing these capabilities to any and all markets that could
potentially use them, is *equally* as important for Embedlets to succeed.

I will take Bruce's following response to the idea of Embedlets having graphic
wiring capabilities as an indication that I am not quite ready to be sent off
to the 'funny farm' just yet: ;-)

>Yes [...] yes [...] yes! [...] Yes [...] Yes [...] YES!!! 


Ted


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

[Embedlets-developer] Re: Development phase game plan

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

Andrzej,

> If you were using the term "development" in a more generic sense (develop 
> the architecture/specs/etc) then I'm in agreement...but would caution you not
> 
> to use a word that can be mis-interpreted so easily by programmer types.

Point taken.  My main idea was to indicate that we were moving out of the
open-ended brainstorming stage and into a getting-down-to-work stage.

If development is not a good word to use here then what is a better way to
describe this phase?


Ted


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

RE: [Embedlets-developer] Lego as a target...

[Christopher S. <cs...@oo...>]

I think that while the Lego system has ties to the toy industry which may be
viewed as less than industrial strength by some  the Mindstorm platform
seems to be a pretty good, low cost platform to prototype and demonstrate
new ideas, especially in wireless, location aware devices, robotics and
educational areas.

AND

Lego could be a substantial supporter/sponsor of the Embedlet standard if it
was proven to be easy enough to deploy at the entry level.

Come to think of it I wouldn't mind sitting at my desktop using a browser to
monitor a lego robot as it looks for the cat...

This brings up another point in that early visibility and buyin by some of
the big players (Dallas, AJile, Systronix, Intel, Lego) in this field should
be one of the goals of this project if we expect it to gain any foothold.
Anyone want to put on their marketing hat?

Chris

-----Original Message-----
From: emb...@li...
[mailto:emb...@li...]On Behalf Of
Andrzej Jan Taramina
Sent: Friday, January 31, 2003 4:10 PM
To: emb...@li...
Subject: [Embedlets-developer] Lego as a target...


Ted and Bruce chat:

> >I suppose that if the graphical wiring aspect of Embedlets were done
right
> >(which is an extremely high priority item on my personal goals list) then
> >it is
> >conceivable that Embedlets might prove to be a good candidate for the
next
> >generation of Lego Mindstorms programming technology.
>
> Yes yes yes!

Since our target was business usage, I am a bit hesitant about tackling Lego
Mindstorms activities with the Embedlets project.  It might damage our
credibility for "real world" applications, which we first set out to
address.

I don't see much need for Lego Mindstorms to integrate with a back end J2EE
or .NET server...which was one of the fundamental goals of Outpost.

That being said, there is no technical reason that someone couldn't use
Embedlets to control Lego Mindstorms, and create a library of useful,
reusable
Lego Mindstorm embedlets.

I just think our initial emphasis should be towards the commercial sector
(process control, shop floor automation, machine monitoring/control for the
manufacturing, distribution and engineering industries), as we had initially
planned.



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] Re: Development phase game plan

[Christopher S. <cs...@oo...>]

I am in full agreement with Andrzej on the limited scope and specification
process. The modular rapid design appoach is to my liking as well.

I have indicated to Ted that I can offload some of the project managment
tasks as I have experience in this area. (not that I like it, I just have to
do it!). Source Forge has some tools for this that I will look into. Ideally
we should be able to put a self-management structure in place that is really
just a status reporting and synchronization procedure.


-----Original Message-----
From: emb...@li...
[mailto:emb...@li...]On Behalf Of
Andrzej Jan Taramina
Sent: Friday, January 31, 2003 4:10 PM
To: emb...@li...
Subject: [Embedlets-developer] Re: Development phase game plan


Ted suggests:

> 1) That we officially choose a project manager for the project.

I vote for Ted as PM.  He's been doing a marvelous job so far....

> I think that everyone would probably agree that we are now ready to start
> tightening up the project and moving on to the project's Development
> phase. Thankfully, the Brainstorming phase of the project has provided a
> rich base of ideas for us to work with.

Actually, Ted, I'm going to be a bit contrary.  I don't think we're ready
for
development yet.  We haven't got an architecture yet....and then we need to
spec out the interfaces and contracts that will make up this architecture.
That
will likely require a lot of brainstorming still. Then we'll be ready to
"develop"
some code.  \

If you were using the term "development" in a more generic sense (develop
the architecture/specs/etc) then I'm in agreement...but would caution you
not
to use a word that can be mis-interpreted so easily by programmer types.

> I think it is important for us to keep in mind that we will be developing
> a full-blown Embedlets specification which should be very similar to the
> Servlet specification.  The current Servlet specification is 257 pages
> long, includes a large number of sections, a significant amount of
> formatting and a very detailed table of contents.

I think that the Embedlets spec needs to be a lot simpler than than the
servlet
spec, otherwise we're going to spend too long on it, and risk making things
a
bit too complicated for developers of Embedlets.  It should also be possible
to
spec out certain areas and then do some prototyping of a reference
implementation while other parts of the spec are still being worked on.
Interative and modular approach....delivery early, deliver often.

Keep in mind that documentation usually lags badly in open source projects.
It
would be nice if Embedlets didn't fall into this trap.

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] Lego as a target...

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

> I don't see much need for Lego Mindstorms to integrate with a
> back end J2EE
> or .NET server...which was one of the fundamental goals of Outpost.

While I love the idea of LEGO also, I tend to agree that we started strongly
on Enterprise applications and have been tempted by other various
applications (PLC's) and now LEGO also. We want to be mindful of these
applications to ensure Embedlets covers it but I tend to agree that
Embedlets focus on Enterprise applications is a good one. For no other
reason that a single Enterprise Applications sale will probably mean more
sales of uVM/JStick/TStick hardware units than all of LEGO unit sales put
together.

The creditability for Mindstorm users to be using 'Industrial Products'
(WOW) on their LEGO products developing real re-usable skills (java) that
can they can phase into their careers is very compelling.

I don't know if it works the other way around though, Enterprise
applications using Toy technologies for their app's. Doesn't come of the
tongue so nicely :-)

Nevertheless - Robots are COOL! and we should certainly make them happen

>All the advanced Lego users are using BrickOS or LeJos, or NQC, so they are
>bypassing the graphical tool because it is far too limited.

Interesting isn't it! Obviously these will be guys developing the Embedlets
while the others will be the one wiring them together to create
applications.

>> Servlet specification.  The current Servlet specification is 257 pages
>> long, includes a large number of sections, a significant amount of
>> formatting and a very detailed table of contents.

>I think that the Embedlets spec needs to be a lot simpler than than the
servlet
>spec, otherwise we're going to spend too long on it, and risk making things
a
>bit too complicated for developers of Embedlets.

I tend to agree with this also. The one feature of Embedlets seems to be its
architectural elegance and flexibility. Complex Systems tend to come from
Simple Rules... I think in order for us to handle the range of applications
we are talking about it will require a simpler specification by natural
complexity rather than a more complex (constrained) one.

Most of the docs will probably not revolve around the spec itself but how to
use the implementations.

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





> -----Original Message-----
> From: emb...@li...
> [mailto:emb...@li...]On Behalf Of
> Andrzej Jan Taramina
> Sent: Saturday, February 01, 2003 11:10 AM
> To: emb...@li...
> Subject: [Embedlets-developer] Lego as a target...
>
>
> Ted and Bruce chat:
>
> > >I suppose that if the graphical wiring aspect of Embedlets
> were done right
> > >(which is an extremely high priority item on my personal goals
> list) then
> > >it is
> > >conceivable that Embedlets might prove to be a good candidate
> for the next
> > >generation of Lego Mindstorms programming technology.
> >
> > Yes yes yes!
>
> Since our target was business usage, I am a bit hesitant about
> tackling Lego
> Mindstorms activities with the Embedlets project.  It might damage our
> credibility for "real world" applications, which we first set out
> to address.
>
> I don't see much need for Lego Mindstorms to integrate with a
> back end J2EE
> or .NET server...which was one of the fundamental goals of Outpost.
>
> That being said, there is no technical reason that someone couldn't use
> Embedlets to control Lego Mindstorms, and create a library of
> useful, reusable
> Lego Mindstorm embedlets.
>
> I just think our initial emphasis should be towards the commercial sector
> (process control, shop floor automation, machine
> monitoring/control for the
> manufacturing, distribution and engineering industries), as we
> had initially
> planned.
>
>
>
> 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
>
>

[Embedlets-developer] Lego as a target...

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

Ted and Bruce chat:

> >I suppose that if the graphical wiring aspect of Embedlets were done right
> >(which is an extremely high priority item on my personal goals list) then 
> >it is
> >conceivable that Embedlets might prove to be a good candidate for the next
> >generation of Lego Mindstorms programming technology.
> 
> Yes yes yes!

Since our target was business usage, I am a bit hesitant about tackling Lego 
Mindstorms activities with the Embedlets project.  It might damage our 
credibility for "real world" applications, which we first set out to address.

I don't see much need for Lego Mindstorms to integrate with a back end J2EE 
or .NET server...which was one of the fundamental goals of Outpost.

That being said, there is no technical reason that someone couldn't use 
Embedlets to control Lego Mindstorms, and create a library of useful, reusable 
Lego Mindstorm embedlets.

I just think our initial emphasis should be towards the commercial sector 
(process control, shop floor automation, machine monitoring/control for the 
manufacturing, distribution and engineering industries), as we had initially 
planned.



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

[Embedlets-developer] Re: Development phase game plan

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

Ted suggests:

> 1) That we officially choose a project manager for the project.  

I vote for Ted as PM.  He's been doing a marvelous job so far....

> I think that everyone would probably agree that we are now ready to start
> tightening up the project and moving on to the project's Development
> phase. Thankfully, the Brainstorming phase of the project has provided a
> rich base of ideas for us to work with.

Actually, Ted, I'm going to be a bit contrary.  I don't think we're ready for 
development yet.  We haven't got an architecture yet....and then we need to 
spec out the interfaces and contracts that will make up this architecture.  That 
will likely require a lot of brainstorming still. Then we'll be ready to "develop" 
some code.  \

If you were using the term "development" in a more generic sense (develop 
the architecture/specs/etc) then I'm in agreement...but would caution you not 
to use a word that can be mis-interpreted so easily by programmer types.

> I think it is important for us to keep in mind that we will be developing
> a full-blown Embedlets specification which should be very similar to the
> Servlet specification.  The current Servlet specification is 257 pages
> long, includes a large number of sections, a significant amount of
> formatting and a very detailed table of contents.

I think that the Embedlets spec needs to be a lot simpler than than the servlet 
spec, otherwise we're going to spend too long on it, and risk making things a 
bit too complicated for developers of Embedlets.  It should also be possible to 
spec out certain areas and then do some prototyping of a reference 
implementation while other parts of the spec are still being worked on.  
Interative and modular approach....delivery early, deliver often.

Keep in mind that documentation usually lags badly in open source projects.  It 
would be nice if Embedlets didn't fall into this trap.

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

[Embedlets-developer] Re: RCX - Advanced alternatives: JCX, Embedlets

[Bruce B. <bb...@sy...>]

At 03:33 AM 1/31/2003 -0800, Ted Kosan wrote:
>Bruce,
>
> > There is also a new 'Embedlet' SourceForge project:
> > http://sourceforge.net/projects/embedlets/
> > which touches on the issue of creating firmware and hardware modules which
> > could easily plug together for variety of applications including robotics.
> > It's all Java and open standards based, and there is a very active mail
> > list. And - it's Open Source. (I'm blind copying the embedlets list with
> > this message). There are some university-level educators active in this
> > project, too.
> >
> > So I am very optimistic about the future of Lego robotics! By this summer
> > there should be a whole raft of interesting new technology available.
>
>As I thought about your post it occurred to me that JCX driven lego mindstorm
>mechanisms would be an excellent way to develop, test and prove the visual
>component assembly aspect of Embedlets.  In fact, the Wiring Tool view of
>Embedlets is similar to a very advanced and generalized version of the current
>graphical RCX programming language.

YES!!! I haven't had a chance to play with your tool yet. Mindstorms has a 
similar visual editor.

>The ideas are similar because Embedlets are configured and snapped together
>just like the various components in the visual RCX language are.  Embedlets,
>however, go on to add the capability to work with any peripheral conceivable,
>run on any platform, and encapsulate a full spectrum of logic from very simple
>up through as sophisticated as Java is capable of producing.
>
>I suppose that if the graphical wiring aspect of Embedlets were done right
>(which is an extremely high priority item on my personal goals list) then 
>it is
>conceivable that Embedlets might prove to be a good candidate for the next
>generation of Lego Mindstorms programming technology.

Yes yes yes!

>Bruce, you are a genious!  I bet that the Lego Mindstorms community has more
>experience than any other group on the planet with 100% graphical 
>snap-together
>programming enviornments based on software components.  These people probably
>know exactly what they would like to see in an Embedlets wiring tool based on
>years of experience with the RCX programming language.

All the advanced Lego users are using BrickOS or LeJos, or NQC, so they are 
bypassing the graphical tool because it is far too limited.

I think they would welcome a powerful Java tool which gave them full blown 
Java code but also a simple visual too for the 10-year olds who want more 
than RCX but aren't ready to write Java from scratch.

>Beyond this, a whole generation of software component application assemblers
>has already been produced by the Mindstorms phenomenon and I bet this group
>will be extremely receptive to being able to leverage this paradigm across the
>whole spectrum of computing as they move into industry.

Yes, for example TCP/IP from JStik, with a browser interface. This is 
pretty much impossible now with the current Lego architecture.

>When work begins on the graphical wiring aspect of Embedlets, I wonder if a
>number of people from the Lego community would be interested in helping us to
>design what the wiring tool should look like and how it should operate?

Yes, when the time is right we can help set that up. For one thing, we need 
the production JCX hardware.

There are some *very* interesting people who have contacted me privately 
and don't want to - or can't - publicly participate on the lists. Some of 
them would make excellent test sites.

Bruce


------- WWW.SYSTRONIX.COM ----------
   Real embedded Java and much more
      High speed 8051 systems
+1-801-534-1017  Salt Lake City, USA 

[Embedlets-developer] Re: RCX & RIS, a fading glory? - Advanced alternatives: JCX, Embedlets

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

Bruce,

> There is also a new 'Embedlet' SourceForge project:
> http://sourceforge.net/projects/embedlets/
> which touches on the issue of creating firmware and hardware modules which 
> could easily plug together for variety of applications including robotics. 
> It's all Java and open standards based, and there is a very active mail 
> list. And - it's Open Source. (I'm blind copying the embedlets list with 
> this message). There are some university-level educators active in this 
> project, too.
> 
> So I am very optimistic about the future of Lego robotics! By this summer 
> there should be a whole raft of interesting new technology available.

As I thought about your post it occurred to me that JCX driven lego mindstorm
mechanisms would be an excellent way to develop, test and prove the visual
component assembly aspect of Embedlets.  In fact, the Wiring Tool view of
Embedlets is similar to a very advanced and generalized version of the current
graphical RCX programming language.

The ideas are similar because Embedlets are configured and snapped together
just like the various components in the visual RCX language are.  Embedlets,
however, go on to add the capability to work with any peripheral conceivable,
run on any platform, and encapsulate a full spectrum of logic from very simple
up through as sophisticated as Java is capable of producing.

I suppose that if the graphical wiring aspect of Embedlets were done right
(which is an extremely high priority item on my personal goals list) then it is
conceivable that Embedlets might prove to be a good candidate for the next
generation of Lego Mindstorms programming technology. 

If Embedlets on muvium works out then a full spectrum of Mindstorm controllers
could be created from muvium based ones that are even cheaper than the current
RCX, through medium cost ones based on JStamp, TStik, and TStamp, up to
extremely powerful ones based on JStik.  Embedlets should run very well across
this whole spectrum of controllers and should only be constrained by the memory
and MIPS capabilities of the hardware they are running on.


Bruce, you are a genious!  I bet that the Lego Mindstorms community has more
experience than any other group on the planet with 100% graphical snap-together
programming enviornments based on software components.  These people probably
know exactly what they would like to see in an Embedlets wiring tool based on
years of experience with the RCX programming language.

Beyond this, a whole generation of software component application assemblers
has already been produced by the Mindstorms phenomenon and I bet this group
will be extremely receptive to being able to leverage this paradigm across the
whole spectrum of computing as they move into industry.

When work begins on the graphical wiring aspect of Embedlets, I wonder if a
number of people from the Lego community would be interested in helping us to
design what the wiring tool should look like and how it should operate?


Ted

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

[Embedlets-developer] Development phase game plan

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

Over the weekend I plan on putting together a summary of the main Embedlet
related ideas that the group has generated in what I call the Brainstorming
phase of this project.  

After this summary is posted early next week I am then going to propose the
following:

1) That we officially choose a project manager for the project.  

I think that everyone would probably agree that we are now ready to start
tightening up the project and moving on to the project's Development phase. 
Thankfully, the Brainstorming phase of the project has provided a rich base of
ideas for us to work with.


2) That the project manager's first task will be to obtain group consensus on
what file format is going to be used for the project's documentation needs.  

I think it is important for us to keep in mind that we will be developing a
full-blown Embedlets specification which should be very similar to the Servlet
specification.  The current Servlet specification is 257 pages long, includes a
large number of sections, a significant amount of formatting and a very
detailed table of contents.

Beyond this, every Sun created Java specification that I am aware of is
published in .PDF format and I think it is important for the Embedlets
specification to follow this pattern too.  For this reason I think that the
documentation file format that we choose must be easily translatable into .PDF
file format.

I do not think that we are going to be able to move forward until we resolve
this documentation file format issue.


Ok, I am off to start combing through the list archives in order to begin
extracting the main Embedlet ideas that we have generated...


Ted

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

[Embedlets-developer] Re: OpenOffice XML file

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

Chris,

> 1. An automatic procedure to extract/reconstitute the documents beween the
> repository tree and the .sxw (zip) format. OpenOffice does have VBA
> compatible automation (hold your yuks, there is room on this planet for a
> few inferior languages)

I researched this and Sun recently released an early access version of their
new Java API for OpenOffice.  It appears that they are working very hard to
make Java the preferred API for extending OpenOffice's capabilities going
forward.  If we end up going with OpenOffice for the project's documentation
needs, I will volunteer to create a plugin for OpenOffice that will
automatically extract/reconstitute the files for use with a CVS.



> I did notice that I could not open a drawing file using WinZip - are the
> other document types stored as xml or just the text and it's embedded
> drawings?

I created a small sxd drawing file and the jar utility unziped it with no
problems.  It consisted of a zipped directory that was very similar to the sxw
file and the content file contained all of the graphics primitives.


Ted

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

[Embedlets-developer] Re: RCX & RIS, a fading glory? - Advanced alternatives: JCX, Embedlets

[Bruce B. <bb...@sy...>]

At 12:26 AM 1/30/2003 -0500, Kyle McDonald wrote:
>Steve Baker wrote:
>>But there is another approach to the hobby - to actually want to build
>>robots that can do meaningful things - that push the envelope of what's
>>possible in robotics - not push the envelope of what's possible with Lego.
>>For people (like me) who want to do those things, the limitations of the
>>RCX are not just an amusing problem to circumvent - they actually prevent
>>you from doing what you'd like to be able to do.   It's extremely frustrating
>>to be in a situation where you could build a really interesting robot - only
>>to find you can't because of the arbitary limit of 3 motors and 3 sensors.
>>Nothing else in Lego is limited in that way.
>I agree with this wholeheartedly. And I think that LEGO is missing
>out on great opportunities in this market because of these limitations.

I agree whole-heartedly.

This is the idea behind JCX which has now been in development for over a 
year, and has been rather extensively alpha-tested at a major university. 
This  past fall students at the University of Utah were able to use the 
CMUCam vision sensor and build *autonomous* (no PC with the camera on it!) 
robots:
http://www.cs.utah.edu/classes/cs4710/teams.html
autonomous checker-playing robot:
http://www.cs.utah.edu/~mundt/cs4710/
soccer playing robots:
http://www.cielguard.com/

We are finally into the move to production on JCX. (If the economy were 
better we'd have been done a year ago.) A JStamp CPU board for JCX is being 
prototyped this week and work on the RFModem is crawling along.

The point of this message is not only a shameless plug for JCX vaporware 
(it's really coming this spring) but to sound an upbeat note that there 
will soon be practical alternatives to the RCX for "real, serious" robots 
using the Lego mechanicals and sensors and motors (also those of HiTechnic 
and other companies).

We plan to sell some kit of JCX sufficient for initial work for about 
US$500, which is a fraction of competitive robot products.

Last year an engineer from Lego in Denmark contacted me and we are planning 
a product swap and further dialog, so, at some level, Lego is aware of and 
interested in JCX. Perhaps Dacta or whomever will pick up JCX once it 
becomes "real" and is shipping.

I realize for the purists this is not an answer simply because Systronix is 
not located in Denmark and is not part of the Lego group. But if all you 
want is a viable, powerful, expandable, open system...

There is also a new 'Embedlet' SourceForge project:
http://sourceforge.net/projects/embedlets/
which touches on the issue of creating firmware and hardware modules which 
could easily plug together for variety of applications including robotics. 
It's all Java and open standards based, and there is a very active mail 
list. And - it's Open Source. (I'm blind copying the embedlets list with 
this message). There are some university-level educators active in this 
project, too.

So I am very optimistic about the future of Lego robotics! By this summer 
there should be a whole raft of interesting new technology available.

Bruce Boyes

http://www.jcx.systronix.com/


------- WWW.SYSTRONIX.COM ----------
   Real embedded Java and much more
      High speed 8051 systems
+1-801-534-1017  Salt Lake City, USA 

RE: [Embedlets-developer] Re: OpenOffice XML file

[Christopher S. <cs...@oo...>]

Just tried a couple of experiments:

Experiment #1 Version Tracking:
1. Enabled the pretty print option.
2. Extracted and committed the doc with text and graphics.
3. Added text, moved graphic and added more graphidcs.
4. Save and extract
5. Ran a diff on content.xml

The result:

1. Text changes are clearly highlighted on a line by line basis - limited by
Araxis' orientation on code diff
2. Graphics are still crammed into one line making it difficult to see the
differences. This may not be an issue as it is probable that one would
replace a drawing wholesale rather than trying to merge minute movements and
sizes etc.


Experiment #2 Document merge:

1. Committed extracted document with text and graphics.
2. Removed the graphics and some formatting
3. Diffed the results and manually merged the graphics and formatting back
into the stripped content.XML
4. Replaced the context.xml with the merged version in the .sxw file, using
WinZip.
5. Saved the file and re-opened in OpenOffice.

The Result:

1. Voila! the graphics and formatting re-appeared exactly as intended.


In order for this to work I think that we would need:

1. An automatic procedure to extract/reconstitute the documents beween the
repository tree and the .sxw (zip) format. OpenOffice does have VBA
compatible automation (hold your yuks, there is room on this planet for a
few inferior languages)

2. Possibly diff/merge tool that has fine grain diff highlighting
capability.

I did notice that I could not open a drawing file using WinZip - are the
other document types stored as xml or just the text and it's embedded
drawings?



-----Original Message-----
From: emb...@li...
[mailto:emb...@li...]On Behalf Of Ted
Kosan
Sent: Thursday, January 30, 2003 12:36 AM
To: emb...@li...
Subject: [Embedlets-developer] Re: OpenOffice XML file


Chris,

> I definitely like the xml form of the extracted documents, it
> seems that we
> have been waiting a long time for a non-proprietary document
> exchange
> format.

I am glad that you see the potential here too.  I know that there are no
guarantees that this will work but I think the potential benefits we would
receive if it does are substantial.



> I guess my general assertion would be that as long as there
> is a clean and
> relatively seamless procedure to collaboratively edit the
> documents and
> track the changes in cvs, I would encourage the group to
> settle on
> OpenOffice as the preferred document editor, with HTML based
> editors as a
> fall back.

I have stated my position on this issue but I am reluctant to move forward
unless most of us agree that this is a good idea.  How do we reach a
consensus?



> 1. The extracted content.xml has no line separators [snip]

OpenOffice comes with its file size optimizations set to 'true'.  In order
to
enable pretty printing of the XML files, go under Tools, Options, Load/Save,
General and turn size optimization off.



> Ted, would you be the one to test and document the cvs
> procedures as they
> relate to OpenOffice?

I would be happy to do this.  Before I start, though, could you please do
the
CVS experiments you did earlier with XML pretty printing turned on and then
report your findings back to the list?


Thanks,


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

[Embedlets-developer] Re: OpenOffice XML file

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

Chris,

> I definitely like the xml form of the extracted documents, it 
> seems that we
> have been waiting a long time for a non-proprietary document 
> exchange
> format.

I am glad that you see the potential here too.  I know that there are no
guarantees that this will work but I think the potential benefits we would
receive if it does are substantial.



> I guess my general assertion would be that as long as there 
> is a clean and
> relatively seamless procedure to collaboratively edit the 
> documents and
> track the changes in cvs, I would encourage the group to 
> settle on
> OpenOffice as the preferred document editor, with HTML based 
> editors as a
> fall back.

I have stated my position on this issue but I am reluctant to move forward
unless most of us agree that this is a good idea.  How do we reach a consensus?



> 1. The extracted content.xml has no line separators [snip]

OpenOffice comes with its file size optimizations set to 'true'.  In order to
enable pretty printing of the XML files, go under Tools, Options, Load/Save,
General and turn size optimization off.



> Ted, would you be the one to test and document the cvs 
> procedures as they
> relate to OpenOffice?

I would be happy to do this.  Before I start, though, could you please do the
CVS experiments you did earlier with XML pretty printing turned on and then
report your findings back to the list?


Thanks,


Ted

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

[Embedlets-developer] Re: OpenOffice XML file formats -> the're zipped!

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

Christopher (or Chris?)

>how do you get XML format documents out of
> the package?

They are zipped!  Create a short text document, save it and then unzip it!  It
is very cool!

Here is where to get all the OpenOffice XML documentation:

xml.openoffice.org


Ted


--- Christopher Smith <cs...@oo...> wrote:
> My apologies OpenOffice 1.0.2 - how do you get XML format documents out of
> the package?
> 
> -----Original Message-----
> From: emb...@li...
> [mailto:emb...@li...]On Behalf Of Ted
> Kosan
> Sent: Tuesday, January 28, 2003 11:50 PM
> To: emb...@li...
> Subject: [Embedlets-developer] Re: OpenOffice
> 
> 
> Christopher,
> 
> > Just a queation on OfficeSuite XML format - I do not see this in the docs
> > that have been posted, they are all binary format. Am I missing something?
> 
> By 'OfficeSuite' do you mean 'OpenOffice' or some other office suite?
> 
> 
> Ted


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

RE: [Embedlets-developer] Re: OpenOffice

[Christopher S. <cs...@oo...>]

My apologies OpenOffice 1.0.2 - how do you get XML format documents out of
the package?

-----Original Message-----
From: emb...@li...
[mailto:emb...@li...]On Behalf Of Ted
Kosan
Sent: Tuesday, January 28, 2003 11:50 PM
To: emb...@li...
Subject: [Embedlets-developer] Re: OpenOffice


Christopher,

> Just a queation on OfficeSuite XML format - I do not see this in the docs
> that have been posted, they are all binary format. Am I missing something?

By 'OfficeSuite' do you mean 'OpenOffice' or some other office suite?


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

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

Hey, looks interesting... I'd be into that I think... do you have some
preferred apps we can evaluate?

- Brill Pappin
  Rogue Robotics
  www.roguerobotics.com


----- Original Message -----
From: "Jac Kersing" <j.k...@th...>
To: <emb...@li...>
Sent: Wednesday, January 29, 2003 2:11 AM
Subject: Re: [Embedlets-developer] Re: OpenOffice


> On Tue, 28 Jan 2003, Ted Kosan wrote:
>
> > What do other people on the list think?  Are we going to encode the core
> > specification documents inside of a modern, open, XML based office suite
> > format or are we going to chisel it into clay tablets? ;-)
>
> How about using DocBook? Still XML but everyone would be able to use their
> own 'pet' editor. And using the right tools it can be published in at
> least HTML, PDF, RTF.
>
> Regards,
>
> Jac
>
> --
>  Jac Kersing            Technical Consultant   The-Box Development
>  j.k...@th...                         http://www.the-box.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
>