[Embedlets-developer] Re: Wiring and hardware...

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

Ted said:

> This is the way I saw the Wiring Tool being developed too.  Embedlets
> should not have any dependencies on a Wiring Tool but they need to be able
> to support manipulation by a Wiring Tool.  Since you have (thankfully!)
> taken the lead on the Embedlets architecture my plan is to put together
> enough of an Alpha level Wiring Tool to be able to provide solid feedback
> to the architecting process.

Super.

But keep in mind that given the very tight constraints we will have on the 
Container architecture/implementation (to squeeze into small devices), and the 
need for code generation to accomplish this, the Container design will 
probably define the XML vocabulary (to a great degree), and thus will drive the 
process.  But that is just syntax.  So long as you design a Wiring tool that can 
generate an XML representation of that wiring, we should be able to bolt the 
two together without much work.

> >Are you suggesting that we develop hardware as well as 
> >the software infrastruction for Outpost?
> 
> You found me out!  Yes, this is exactly what I am proposing and this is
> what I and some of the developers on the Cork list have been researching
> as a side project. 

OK.  I have no problem with that. But trying to define and set hardware 
standards (where those don't already exist) might be a tough thing without the 
backing of larger players (Dallas, Systronix/aJile, PIC, etc.).

So long as it stays a "side project" to the Outpost Container development.  
Trying to integrate all of these efforts into one will make the whole too big and 
unmanageable.  I see that we already have 5 concurrent subprojects loosely 
defined:

1) Outpost Container for Embedlets  (the software infrastructure)
2) Graphical Wiring Tool
3) JAPL specification and concrete implementations
4) Hardware interface standardization/development.
5) uVM 

It also looks like we are naturally specializing in the areas that interest us the 
most as follows (same numbering as the above....and not this does not mean 
that you're not interested in the other areas...just a primary interest):

1) Andrzej
2) Ted
3) CORK team
4) CORK team
5) James

Funny how that is shaping up. ;-)

> So what was so different about the IBM XT that all of a sudden it
> caused this toy market to became legitimate? 

Lotus 1-2-3 was the "disruptive" technology back then that caused this 
market/technology shift.  I want Embedlets to be the 1-2-3 of the early 2000's 
embedded area!

> Why do you say they have not succeeded?  Most Java applications that use AWT
> and Swing use lots of JavaBeans components and every modern Java IDE supports
> graphic configuration of JavaBeans using an inspector. 

They have them....but they are rarely used for commercial software because 
the "glue" code they generate is abysmally unmaintainable.  And any real app 
developer soon discovers that they HAVE TO maintain and change the ugly 
generated code. Any decent Java programmer can slap together a 
Swing/AWT UI just as fast using code...which IS extensible and maintainable.  
That is why I say it hasn't succeeded...it provides little benefit except for 
trivially simple applications.  Graphical construction of UI's using JavaBeans 
for anything but simple, one-use applications is just not practical for real-world 
applications.  Graphical creation of UI apps using IDE's was a futile attempt to 
take junior/intexperienced programmers and make them as productive as the 
expert/seniors.  Problem is it doesn't work...and likely is not going to for quite 
some time. 

JB's are used for many things (I use them all the time)...so what I should have 
said is that they have not succeeded as a Graphical Component Assembly 
technology.

Brill gets swamped:

> Sheesh... I'm not paying attention for a couple of days, and the list fills
> up!

Yup...ya gotta pay attention! ;-)

Some great discussion and massive traffic on the list this weekend.  
Awesome!

Then Brill adds:

> it must be able to connect to a standard telephone line

Aw man!  Not the aJile PPP stack thread again (subtly disguised). <grins>

and:

> How many of us have architecture experience from the *start*?

Moi.

> Personally, I love "just doing it" but I think for this one, with so many
> active people working on it, we definitely need a little more structure.

Given the challenges we face in marketing, adoption, constrained devices and 
such, "just doing it" (eg. hacking some code), plus the challenges of group-
development of Open Source (mainly communications issues) will not achieve 
the lofty goals we set out for Outpost.  A more structured approach is 
warranted (for all facets:  design/architecture/vision, documentation, project 
structure, etc.)

> Hmm... maybe someone needs to write up a "manifesto" or something ;)

Hold that thought, Brill (from an Container architecture & vision perspective)! 

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