embedlets-developer Mailing List for Outpost Embedlet Container (Page 36)
Status: Alpha
Brought to you by:
tkosan
Menu
▾
▴
embedlets-developer — Outpost Embedlet container developer list
You can subscribe to this list here.
| 2003 |
Jan
(135) |
Feb
(402) |
Mar
(162) |
Apr
(22) |
May
(13) |
Jun
(67) |
Jul
(59) |
Aug
(27) |
Sep
(1) |
Oct
(28) |
Nov
(81) |
Dec
(16) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(2) |
Feb
(21) |
Mar
(6) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
(13) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2006 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Brill P. <bri...@ro...> - 2003-02-02 10:27:28
|
Hey, cool... Really a Wiki is the way we want to go, but I think it would require hosting on someones server... > 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 Hey, it does look good... have you guys got a desktop app for it yet (or will you)? Guess I could build one... but I'm so swamped I'd get it working, then leave you all to deal with it ;) - Brill Pappin |
|
From: Brill P. <bri...@ro...> - 2003-02-02 10:22:08
|
> > 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? Definitely something that needs doing... but I agree we need a more solid basis to speak from... and lets be frank, we also don't want one of the big boys coming in and taking it over. We are building something of a co-operative company here, whether we recognize that or not. Hmm... maybe someone needs to write up a "manifesto" or something ;) - Brill Pappin |
|
From: Brill P. <bri...@ro...> - 2003-02-02 10:22:01
|
I don't think he wants to "shutdown" the brainstorming... however I do think we should be starting on the documentation, at least on the user requirements level... it will also help us solidify some of the ideas, and point out places where we're missing critical components... I see the docs a mutable, until frozen for a release ;) - Brill Pappin > > 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? |
|
From: Brill P. <bri...@ro...> - 2003-02-02 10:16:42
|
design, requirements management ;) - Brill Pappin > If development is not a good word to use here then what is a better way to > describe this phase? |
|
From: Brill P. <bri...@ro...> - 2003-02-02 10:16:35
|
> 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. The sourcefore tools are fairly good... allowing task assignment and tracking... as well as documentation etc. (I've also got a little experience in management, but I'm not volunteering as I'm way too busy as it is). What might be a good way to go about the specs, is to assign portions of them to individuals for a period of time, then rotate them... now that I think about it, that might be a very good way to do it, a sort of modified pair-programming model ;) Anyway, we can start on setting up the task tracking etc, ASAP, as it will help give some structure to what we're doing. - Brill Pappin |
|
From: Brill P. <bri...@ro...> - 2003-02-02 10:11:15
|
> 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" I don't think we even really have the user requirements yet, let alone the technical specs... How many of us have architecture experience from the *start*? Maybe someone could "port" a template document over for us, once we have the document format sorted out... I have some myself... in Word of course ;) but they could be easily ported to whatever we're going to use. 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. - Brill Pappin |
|
From: Brill P. <bri...@ro...> - 2003-02-02 10:11:08
|
> 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 agree here... we've already created a beast that could kill us in complexity if we're not carefule, and the original point to all this was a way to bring the stuff we love into the corporate as a viable alternative (or even "killer app"). Though I love lego, I think the Lego guys will take it and utilize it to their harts content anyway, and we don't need to do anything "special" to enable that sort of usage. - Brill Pappin |
|
From: Brill P. <bri...@ro...> - 2003-02-02 10:05:55
|
Sheesh... I'm not paying attention for a couple of days, and the list fills up! > 1) That we officially choose a project manager for the project. I think thats you Ted! can't get out of it that easy ;) [...] > 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. PDF is fairly easy... there are even Java libs for it ;) however that doesn't make it easy to edit them, only for the stuff we release. > I do not think that we are going to be able to move forward until we resolve > this documentation file format issue. Well.. you know my spin on that one ;) Text or HTML are my vote... > Ok, I am off to start combing through the list archives in order to begin > extracting the main Embedlet ideas that we have generated... Got a few more aspects I've been thinking about... it must be able to connect to a standard telephone line and be battery powered so that it can monitor not only things like temperature, but also other machines (servers etc...) and power requirements... with a telephone line, and battery operation, it could actually call someone and tell them they where about to have a big mess on their hands. e-mail as well... so notices can go out on several different mediums... I'm sure we can expand on that one ;) - Brill Pappin |
|
From: Ted K. <tk...@ya...> - 2003-02-02 09:53:23
|
Andrzej, >No problem there...this [Wiring Tool] could easily be a separate but parallel subproject. 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. >How do you propose we mitigate the hardware interfacing >problem? It's probably beyond this group to define plug >'n play cabling and interfacing standards for hardware, >though Systronix and such could tackle that and have to >some degree. > >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. At this point it looks like all of the 1-Wire devices (accessed through the 1-Wire Java API) can be used as a base for Plug-and-play I/O modules by placing tags inside of them that indicate what JAPL interface the module they are a part of implements. Each PnP I/O module is designed to implement one or more JAPL interfaces and as they are plugged into a live Outpost an instance of the JAPL peripheral that is used to communicate with the module automatically appears in a pallet in the Wiring Tool. The graphic representation of this module can then be selected and dropped into the wiring area where it can be configured using an inspector and then wired to Embedlets as needed. Everything is done 'live' so state changes happening in the JAPL peripheral are reflected in its companion I/O module and state changes happening in the I/O module are reflected in the JAPL peripheral. The cabling and connector standard for 1-Wire modules have already been developed so this can be leveraged directly. 1-Wire based modules should be adequate for architecting the PnP software layers that will need to be created and also for satisfying the initial sensing needs of early Outpost adopters. The next logical step up from a 1-Wire network appears to be an I2C based PnP network and initial steps are already being taken in this direction too. For instance, the new TStik socket board has an I2C buffer included on it to support a usable I2C network length. Aside from normal I2C devices I think that this network will work very will with PnP modules based on muvium. Finally, the Systronix JSimm boards are also scheduled to have 100% PnP capabilities in the near future and they should integrate nicely with the JAPL based PnP I/O module software specification we possibly will be developing. The whole Graphic Wiring Tool idea depends on having I/O modules available that can be wired to an Outpost in realtime and I have been working very hard to help make this a reality. I have not talked too much about this on the list yet because I did not want people to tell me that it was a bad idea and that it would not work. ;-) >>Success with a graphical wiring application that has access to only a >>handful of components is easily seen with the Lego mindstorms environment. >> This environment contains a small, fixed number of well-chosen components >>and it has done very well in the marketplace. > >I suspect this is not a fair comparison, since this is >a toy market. The majority of buyers will stick to the >constraints of the platform, since they are only playing. But Andrzej, back in the 70s and early 80s, the PC market was only a 'toy' market too dominated by Apple IIs, Commodores, TRS-80s, Ataris and Timex Sinclairs and people were only 'playing' with these machines too. So what was so different about the IBM XT that all of a sudden it caused this toy market to became legitimate? I am not saying that Legos are going to be used for industrial applications. My position is that the graphic assembly of software components paradigm has been well proven to work for a wide range of functioning (albeit simple) applications and that this paradigm should be transferable to industry. I think that Embedlets have a shot at bringing some legitimacy to this market. >JavaBeans do not have such an design foundation, and have not >succeeded. Hmmmm.... 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. I would agree that a strong market for JavaBeans components has not developed but Sun states that a significant reason for this was the lack of a robust long term persistence mechanism. The long term persistence API has fixed this problem. Despite the presence of the BeanContext container, however, I agree with you that JavaBeans could have been architected better (especially the event mechanism). Anyway, I have not once argued against having a rock-solid design foundation for Embedlets if for no other reason than my name will be on the specification too! ;-) >Sounds like we might be in violent agreement on the fundamental >points here... Yes, again, I am with you. I primarily wanted to work through some of these issues before the architecting process moved too far along. Ted __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |
|
From: Christopher S. <cs...@oo...> - 2003-02-02 09:09:09
|
Ted, I agree with your analysis of the current state of affairs, however, in the development world things do change in a positive-feed-back manner ie: rapidly once initiated. I recall getting the first 'C' compiler for the 8051, way back in the last century, when the only way to program the damn things was with the manufacturers' assembly language tools. There was a fair amount of resistence because engineers were comfortable twiddling bits and were not interested in going back to school to learn to program. It took a while but now 'C' is King and most engineers can deal with it pretty well. The same thing will happen with embedded Java, especially if forward looking companies like Dallas back it and provide plug-in drivers rather than publish a little vague 6800 code and expect everyone to create their own bit- banger routines. Ted, Great diagram Ted and I completely agree. A = Embedded Systems Programmers B = Enterprise Systems Programmers C = A + B Looks like a fantastic opportunity for C to create a bridge for A and B to work together. I don't think A will(or wants to) learn B anytime soon and I don't think B will(or wants to) learn A anytime soon BUT I think we are on the right track with the legacy wrapper technologies. It makes sense and has historical precendent. (A) takes their interfaces and driver experitise and wrap them into Java wrappers compliant with the JAPL interface. They then Register their new platform dependent JAPL object with Embedlets.source forge and get credit for moving the world to a better place. (B) takes their java language and abstract cleverness and wrap up their idea's as generic re-useable Embedlets and then Register their new Embedlet with Embedlets.source forge and get credit for moving the world to a better place. (C) contribute by creating the Embedlets specification and reference implementation framework in the first place and also go about the business of writing the cork abstract versions of JAPL libraries which over time replace the platform dependent versions of the JAPL libraries. Then A or B or C use Ted's now very FAMOUS! graphical wiring tool , or an XML editor ;-) , and drag and drop Embedlets and JAPL components to create entire interconnected systems ranging from the latest tamogotchi through the weather bureau's initiative to record the temperature of every square centimeter of the planet. Sounds like a good 'co-operative' open source project to me! James Caska http://www.muvium.com 'Java Bred for Embedded' > -----Original Message----- > From: emb...@li... > [mailto:emb...@li...]On Behalf Of Ted > Kosan > Sent: Sunday, February 02, 2003 6:48 PM > To: emb...@li... > Subject: [Embedlets-developer] RE: W hy Embedded Java is floundering > > > Bruce, > > >>So, after working extremely hard for years to > >>help 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. > > > > "All" it would take to break through this inertia is some very > compelling > > applications.[snip] > > Here is the reason that Embedded Java has floundered in the > marketplace since > it was introduced in the mid 1990s: > > http://tkosan.javadevices.org/misc/embeddedjava/flounder.jpg > > Even without the help of very compelling applications Embedded > Java is more > than compelling enough already. It is not compellingness that is the > constraint here, it is the extreme difficulty of becoming skilled in 2 > extremely demanding disciplines in order to us it. > > > > > But what about the success of tools like Ant that *do* require > people to > > think and program in new ways? The secret here, I think, is > that Ant meets > > a need which is not addressed by any other solution. In other > words, it's > > very compelling. > > Ant is still mostly just Java and it targets a market that > consists of millions > of existing Java programmers. It takes a Java programmer much > less than a day > to start using Ant because they can easily leverage their exiting > Java skills > when learning how to use it. > > My position is that any product or tool that requires an > individual to know > both computer interfacing and object oriented Java programming is > going to fail > because the Embedded Java developer pool contains an estimated > <10000 members > and it is growing very slowly. > > At least half the battle here is to simply acknowledge this to be > a fact and > then figure out a way to work around it. If even just for the > sake of argument > one accepts this position to be true, what do the possible > workaround solutions > look like? > > > 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 > > ------------------------------------------------------- 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 |
|
From: James C. <ca...@vi...> - 2003-02-02 08:19:27
|
Ted, Great diagram Ted and I completely agree. A = Embedded Systems Programmers B = Enterprise Systems Programmers C = A + B Looks like a fantastic opportunity for C to create a bridge for A and B to work together. I don't think A will(or wants to) learn B anytime soon and I don't think B will(or wants to) learn A anytime soon BUT I think we are on the right track with the legacy wrapper technologies. It makes sense and has historical precendent. (A) takes their interfaces and driver experitise and wrap them into Java wrappers compliant with the JAPL interface. They then Register their new platform dependent JAPL object with Embedlets.source forge and get credit for moving the world to a better place. (B) takes their java language and abstract cleverness and wrap up their idea's as generic re-useable Embedlets and then Register their new Embedlet with Embedlets.source forge and get credit for moving the world to a better place. (C) contribute by creating the Embedlets specification and reference implementation framework in the first place and also go about the business of writing the cork abstract versions of JAPL libraries which over time replace the platform dependent versions of the JAPL libraries. Then A or B or C use Ted's now very FAMOUS! graphical wiring tool , or an XML editor ;-) , and drag and drop Embedlets and JAPL components to create entire interconnected systems ranging from the latest tamogotchi through the weather bureau's initiative to record the temperature of every square centimeter of the planet. Sounds like a good 'co-operative' open source project to me! James Caska http://www.muvium.com 'Java Bred for Embedded' > -----Original Message----- > From: emb...@li... > [mailto:emb...@li...]On Behalf Of Ted > Kosan > Sent: Sunday, February 02, 2003 6:48 PM > To: emb...@li... > Subject: [Embedlets-developer] RE: W hy Embedded Java is floundering > > > Bruce, > > >>So, after working extremely hard for years to > >>help 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. > > > > "All" it would take to break through this inertia is some very > compelling > > applications.[snip] > > Here is the reason that Embedded Java has floundered in the > marketplace since > it was introduced in the mid 1990s: > > http://tkosan.javadevices.org/misc/embeddedjava/flounder.jpg > > Even without the help of very compelling applications Embedded > Java is more > than compelling enough already. It is not compellingness that is the > constraint here, it is the extreme difficulty of becoming skilled in 2 > extremely demanding disciplines in order to us it. > > > > > But what about the success of tools like Ant that *do* require > people to > > think and program in new ways? The secret here, I think, is > that Ant meets > > a need which is not addressed by any other solution. In other > words, it's > > very compelling. > > Ant is still mostly just Java and it targets a market that > consists of millions > of existing Java programmers. It takes a Java programmer much > less than a day > to start using Ant because they can easily leverage their exiting > Java skills > when learning how to use it. > > My position is that any product or tool that requires an > individual to know > both computer interfacing and object oriented Java programming is > going to fail > because the Embedded Java developer pool contains an estimated > <10000 members > and it is growing very slowly. > > At least half the battle here is to simply acknowledge this to be > a fact and > then figure out a way to work around it. If even just for the > sake of argument > one accepts this position to be true, what do the possible > workaround solutions > look like? > > > 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 > > |
|
From: Ted K. <tk...@ya...> - 2003-02-02 07:48:07
|
Bruce, >>So, after working extremely hard for years to >>help 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. > > "All" it would take to break through this inertia is some very compelling > applications.[snip] Here is the reason that Embedded Java has floundered in the marketplace since it was introduced in the mid 1990s: http://tkosan.javadevices.org/misc/embeddedjava/flounder.jpg Even without the help of very compelling applications Embedded Java is more than compelling enough already. It is not compellingness that is the constraint here, it is the extreme difficulty of becoming skilled in 2 extremely demanding disciplines in order to us it. > But what about the success of tools like Ant that *do* require people to > think and program in new ways? The secret here, I think, is that Ant meets > a need which is not addressed by any other solution. In other words, it's > very compelling. Ant is still mostly just Java and it targets a market that consists of millions of existing Java programmers. It takes a Java programmer much less than a day to start using Ant because they can easily leverage their exiting Java skills when learning how to use it. My position is that any product or tool that requires an individual to know both computer interfacing and object oriented Java programming is going to fail because the Embedded Java developer pool contains an estimated <10000 members and it is growing very slowly. At least half the battle here is to simply acknowledge this to be a fact and then figure out a way to work around it. If even just for the sake of argument one accepts this position to be true, what do the possible workaround solutions look like? Ted __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |
|
From: Christopher S. <cs...@oo...> - 2003-02-02 07:31:32
|
< 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. Maybe he has, but is so efficient that he came in at 30% of the budget and 6 months early! Andrzej, you have been milking your clients too long! |
|
From: Christopher S. <cs...@oo...> - 2003-02-02 06:21:04
|
Andrzej, Thats great! I will defer to your judgement on this - an area that I usually fumble with. -----Original Message----- From: emb...@li... [mailto:emb...@li...]On Behalf Of Andrzej Jan Taramina Sent: Saturday, February 01, 2003 7:05 AM To: emb...@li... Subject: [Embedlets-developer] Re: Marketing 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 ------------------------------------------------------- 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 |
|
From: James C. <ca...@vi...> - 2003-02-02 05:49:20
|
>Disruptive technologies are rarely (if ever) >adopted by the incumbents, since they have too much vested interest. Interestingly this is a key strategy for uVM. Because I am not competing with Microchip rather I am building a bridge for them to enter the java market I am hoping to get uVM to be a linecard product for Microchip and then for others also.. The symbiance is very natural and is totally in line with their long term wireless objectives.. If this was achieved, Java could 'just happen' in this market segment - like a phase shift. But to do this Java has to have no 'down side' This is not a $50M cash burned prediction but my gut is telling me it could happen (or is that just wishful thinking..) James Caska http://www.muvium.com 'Java Bred for Embedded' |
|
From: James C. <ca...@vi...> - 2003-02-02 05:43:51
|
> So how do you propose we slay the C library dragon? > >There is nothing that says we can't wrap C libraries in a Java/JAPL wrapper to >leverage existing device driver libraries, for those platforms that will support >this. Thats exactly what I propose. 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 4:20 PM > To: emb...@li... > Subject: [Embedlets-developer] Re: Slaying the C library dragon? > > > James said: > > > I would argue that it is the packages that made java not the > language. Su= > > n built the packages. > > I would concur with this assesment, though the inherently more robust and > reliable code (no pointers) that Java produces, along with it's improved > security model did help adoption as well. > > > Java however has the advantage that its library can go > further.. ie it is > > inherintly more re-useable than C. The issue is that the C libraries are > > 80/20 libraries so are hard to slay. > > So how do you propose we slay the C library dragon? > > There is nothing that says we can't wrap C libraries in a > Java/JAPL wrapper to > leverage existing device driver libraries, for those platforms > that will support > this. > > > 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 > > |
|
From: Andrzej J. T. <an...@ch...> - 2003-02-02 05:21:57
|
Chris suggests.... > That being the case I would recommend: ...and I concur for the most part. > 1. We concentrate on the core Embedlet technology to let us quickly > produce a standard with a demonstratable reference implementation. This is probably going to take longer than anyone expects. Open source development produces good product, especially for infrastructure/plumbing applications, but it does take longer than you think. > 2. We create a simple, flexible communication protocol that will > accomodate any XML, TCP/IP capable system. HTTP and XML out of the box! Yup! I vote for that! > 3. We create demonstration GUI based configuration and monitoring tools. > At least a JavaBean/Swing component that can be used as a bsisi for > extension. This, I have found from experience, is the 'easy' part as long > as the underlying technology is simple and directly exposed as it is in > XML. No problem there...this could easily be a separate but parallel subproject. Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Andrzej J. T. <an...@ch...> - 2003-02-02 05:21:54
|
James said: > I would argue that it is the packages that made java not the language. Su= > n built the packages. I would concur with this assesment, though the inherently more robust and reliable code (no pointers) that Java produces, along with it's improved security model did help adoption as well. > Java however has the advantage that its library can go further.. ie it is > inherintly more re-useable than C. The issue is that the C libraries are > 80/20 libraries so are hard to slay. So how do you propose we slay the C library dragon? There is nothing that says we can't wrap C libraries in a Java/JAPL wrapper to leverage existing device driver libraries, for those platforms that will support this. Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Andrzej J. T. <an...@ch...> - 2003-02-02 05:21:50
|
Ted clarifies: > So the constraint is the interfacing hardware and the specialized > programming techniques involved in controlling it. Embedlets can handle the second issue. How do you propose we mitigate the hardware interfacing problem? It's probably beyond this group to define plug 'n play cabling and interfacing standards for hardware, though Systronix and such could tackle that and have to some degree. Are you suggesting that we develop hardware as well as the software infrastruction for Outpost? > At least for my initial pet target market, I envision that the number of > Embedlets needed at first will be fairly small. The reason for this is > that even though enterprises will eventually need sophisticated monitoring > capabilities, they are currently just getting started with this effort and > they are not capable of handling anything more sophisticated than reading > simple physical quantities like temperatures, pressures and switch states. > A relatively few well-chosen Embeldets, along with a clean way to submit > measurements to an enterprise system, will be more than enough to get > started with. I think you'll find that once a company/developer gets the few simple ones running, they will immediately start thinking of more complex applications (even the Lego hobbyists have followed this pattern). And the underlying container platform had better be designed such that they can address that. It seems to be the pattern that technology adoption follows. Just the number of potential temp/pressure/sensor devices out there makes this a challenge to deliver, since out of the box hobbyist sensors are not likely to stand up in the harsh world of a production floor. > Success with a graphical wiring application that has access to only a > handful of components is easily seen with the Lego mindstorms environment. > This environment contains a small, fix number of well-chosen components > and it has done very well in the marketplace. I suspect this is not a fair comparison, since this is a toy market. The majority of buyers will stick to the constraints of the platform, since they are only playing. I don't think the same market dynamics and customer requirements will apply to the manufacturing and distribution industries. But even with that said, a non-trivial number of Lego customers have gone on to code their own lower level stuff....we need that capability as well and probably on day one, since it could easily turn the tide against us if the system has artificial road blocks that prevent addressing of custom requirements. > So, a full-blown Embedlet market is not needed up front to get started in > most areas and my pet target market was never dependent on such a market. Let's agree to disagree on this point. I believe that the advanced capabilities, and a rock solid architectural foundation will be critical to longer term success, as it was with Servlets/EJBs/J2EE. Interestingly enough, JavaBeans do not have such an design foundation, and have not succeeded. Hmmmm.... > I think that James and Bruce could add much to the discussion here. My > perspective is that it is going to take years for us to see anything even > approaching a significant number of these low-level programmers migrating to > Java. Over at least the next 3 years I think the best we can achieve is to > allow them to easily attach their legacy and current systems to a network using > some technique that does not require them to program in Embedded Java. I don't think the first wave of sophisticated users (be it by evolution from the Graphical Tool, or through existing experience with other Component technologies) will be the existing C/C++/Asm Embedded programmers. That was much of my point. There are probably already as many if not more MIDP embedded Java programmers than all the C/C++/Asm guys put together, and if that isn't the case, it looks like it will be soon. So I don't envision targeting the "established" embedded development market. I think this has the prospect of being a "disruptive" technology and defining a new market segment, which eventually could eclipse and replace the older way of doing embedded systems. Disruptive technologies are rarely (if ever) adopted by the incumbents, since they have too much vested interest. > I think that muvium address this need brilliantly for the PIC community. > Muvium will enable an assembly-language-only PIC programmer to develop an > embedded solution in 100% PIC assembly language and then they can graphically > wrap it in a JAPL object, wire it to an Outpost and from there wire it to a > wide number of things from PLCs to backend enterprise systems. Agreed...there is no reason that you shouldn't be able to take C or Asm code and expose it through a JAPL interface. And if you do that, then Embedlets won't care....they will think they are talking to a Java Device Driver since the underlying implementation language will be encapsulated and hidden. But to run on a PIC (with something like uVM) we'll need an Embedlet container that is very lean and mean! That is something that I strongly support. But I do want to see the container run on aJile chips (Systronix boards) and on PC's as well (the latter for development/testing purposes if nothing else, though I do see a role for PC's in the upper end of the embedded space too) Sounds like we might be in violent agreement on the fundamental points here.... Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: James C. <ca...@vi...> - 2003-02-02 05:20:33
|
Bruce, All I can say is that we have a lot in common. Looking forward to those drinks someday :-) James Caska http://www.muvium.com 'Java Bred for Embedded' > -----Original Message----- > From: emb...@li... > [mailto:emb...@li...]On Behalf Of > Bruce Boyes > Sent: Sunday, February 02, 2003 4:08 PM > To: emb...@li... > Subject: [Embedlets-developer] Lego, markets, disruption, trade shows > 2003, etc > > > At 02:46 AM 2/1/2003 -0800, > emb...@li... wrote: > 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. > > That's OK, I wasn't suggesting that embedlets change direction. We're > addressing the "advanced" Lego market for a a variety of business and > technical reasons which don't have to share much - or anything - > with your > reasons for embedlets. > > > >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. > > Bingo! Chris has got it. > > >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. > > Don't hold your breath for this one. Lego is *huge* and JCX/Systronix is > not even on their radar screen. We're smaller than a speck on their > windshield. I don''t mean this pejoratively at all. The Lego > folks probably > get letters every day from well-intentioned people who think they > have the > greatest idea since sliced bread. Lego is very focused and exceptionally > good at what they do, and they can't get too sidetracked from that. > > It's more likely that the eduational arm of Lego, Pitsco-Legodacta (what > does that name mean?) http://www.pitsco-legodacta.com/ might be > interested > in some of this, but only when it's demonstrable. Great ideas are > about $1 > per 1000. > > >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 summer if all goes well, you will be able to do just that. > > >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). > > I would recommend the book "The Innovator's Dilemma" > http://www.amazon.com/exec/obidos/tg/detail/-/0875845851/qid=10441 > 59725/sr=8-2/ref=sr_8_2/102-9445003-7535349?v=glance&s=books > > Summary: you can't reasonably view a new, 'disruptive' technology > from the > perspective of the status quo. Well, you can, but 90% of the time > you will > come to the wrong conclusions. That's the premise of this book, based on > case studies of new technologies with which we are all familiar. > > After talking to several hundred developers at trade shows the last four > years, thousands of emails, etc, and being one of the "status quo" > developers (C, assy, traditional 8- to 32- bit embedded micros) I have > changed my ideas about marketing embedded Java. I could (a) be completely > wrong, and (b) I'd rather discuss this over drinks, and (c) I > don't want to > share my theories with the world -- so I won't say more here. > > >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. > > Here's where Ted and I are going different directions (but still working > together on some of the same goals). I just don't have a clue at > the moment > how to market to this group of folks, but I think it's good that Ted and > others are thinking about them. > > >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. > > "All" it would take to break through this inertia is some very compelling > applications. There are some we are aiming at and should have shipping by > summer 2003. Will they be the killer app we are seeking? Dunno. > > >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. > > But what about the success of tools like Ant that *do* require people to > think and program in new ways? The secret here, I think, is that > Ant meets > a need which is not addressed by any other solution. In other words, it's > very compelling. > > >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. > > Dinner sometime is the best place to get me to discuss this. I > don't share > the same perspective. But I could be wrong. > > I'll go back to lurking now, for a while, at least. One parting thought: > > Get something working ASAP and get it into the hands of users. > Almost every > time we have done so, the users have led us in an unexpected > direction. You > just can't get very far theorizing, you have to implement and then listen > to what people say, and interpret that into what they mean, then try to > deliver that. Then keep iterating until you get there. See this book: > http://www.amazon.com/exec/obidos/tg/detail/-/0471292524/qid=10441 61150/sr=1-1/ref=sr_1_1/102-9445003-7535349?v=glance&s=books Or put another way "the difference between theory and practice, while small in theory, is large in practice". There are a number of high profile embedded companies I've been more or less following who have each burned through upwards of $50 million in venture funding and still have no clear market or customer base. They've had several detailed roadmaps in the last five years. Tons of PR and glitzy marketing. Problem was, no one wanted to go where they were leading. It's interesting and potentially educational to try to understand where they failed and why. On the other hand look at Rational and TogetherSoft. Why have they succeeded so well and been able to cash out very profitably even in a down economy? (More dinner topics). So one really, final, parting shot. The big tradeshows for us are ESC West in SFO April 23-25: http://cmp.iconvention.com/sf/v33/index.cvn?id=10008&stab=2 and JavaOne also in SFO, June 10-13: http://servlet.java.sun.com/javaone/sf2003/home/index.en.jsp We have booths reserved at both the above. We might also do the embedded east show in BOS Sep 15-18 http://esconline.com/boston/ So I'd encourage you all to try to have something to show at each of these. We can discuss providing some space in our booth when the time gets closer and the product gets "realer". Let me know if there is anything reasonable Systronix can do to help. For now, we'll provide some of the hardware blocks for you to wrap code around. Bruce ------------------------------------------------------- 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 |
|
From: Bruce B. <bb...@sy...> - 2003-02-02 05:08:18
|
At 02:46 AM 2/1/2003 -0800, emb...@li... wrote: 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. That's OK, I wasn't suggesting that embedlets change direction. We're addressing the "advanced" Lego market for a a variety of business and technical reasons which don't have to share much - or anything - with your reasons for embedlets. >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. Bingo! Chris has got it. >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. Don't hold your breath for this one. Lego is *huge* and JCX/Systronix is not even on their radar screen. We're smaller than a speck on their windshield. I don''t mean this pejoratively at all. The Lego folks probably get letters every day from well-intentioned people who think they have the greatest idea since sliced bread. Lego is very focused and exceptionally good at what they do, and they can't get too sidetracked from that. It's more likely that the eduational arm of Lego, Pitsco-Legodacta (what does that name mean?) http://www.pitsco-legodacta.com/ might be interested in some of this, but only when it's demonstrable. Great ideas are about $1 per 1000. >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 summer if all goes well, you will be able to do just that. >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). I would recommend the book "The Innovator's Dilemma" http://www.amazon.com/exec/obidos/tg/detail/-/0875845851/qid=1044159725/sr=8-2/ref=sr_8_2/102-9445003-7535349?v=glance&s=books Summary: you can't reasonably view a new, 'disruptive' technology from the perspective of the status quo. Well, you can, but 90% of the time you will come to the wrong conclusions. That's the premise of this book, based on case studies of new technologies with which we are all familiar. After talking to several hundred developers at trade shows the last four years, thousands of emails, etc, and being one of the "status quo" developers (C, assy, traditional 8- to 32- bit embedded micros) I have changed my ideas about marketing embedded Java. I could (a) be completely wrong, and (b) I'd rather discuss this over drinks, and (c) I don't want to share my theories with the world -- so I won't say more here. >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. Here's where Ted and I are going different directions (but still working together on some of the same goals). I just don't have a clue at the moment how to market to this group of folks, but I think it's good that Ted and others are thinking about them. >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. "All" it would take to break through this inertia is some very compelling applications. There are some we are aiming at and should have shipping by summer 2003. Will they be the killer app we are seeking? Dunno. >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. But what about the success of tools like Ant that *do* require people to think and program in new ways? The secret here, I think, is that Ant meets a need which is not addressed by any other solution. In other words, it's very compelling. >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. Dinner sometime is the best place to get me to discuss this. I don't share the same perspective. But I could be wrong. I'll go back to lurking now, for a while, at least. One parting thought: Get something working ASAP and get it into the hands of users. Almost every time we have done so, the users have led us in an unexpected direction. You just can't get very far theorizing, you have to implement and then listen to what people say, and interpret that into what they mean, then try to deliver that. Then keep iterating until you get there. See this book: http://www.amazon.com/exec/obidos/tg/detail/-/0471292524/qid=1044161150/sr=1-1/ref=sr_1_1/102-9445003-7535349?v=glance&s=books Or put another way "the difference between theory and practice, while small in theory, is large in practice". There are a number of high profile embedded companies I've been more or less following who have each burned through upwards of $50 million in venture funding and still have no clear market or customer base. They've had several detailed roadmaps in the last five years. Tons of PR and glitzy marketing. Problem was, no one wanted to go where they were leading. It's interesting and potentially educational to try to understand where they failed and why. On the other hand look at Rational and TogetherSoft. Why have they succeeded so well and been able to cash out very profitably even in a down economy? (More dinner topics). So one really, final, parting shot. The big tradeshows for us are ESC West in SFO April 23-25: http://cmp.iconvention.com/sf/v33/index.cvn?id=10008&stab=2 and JavaOne also in SFO, June 10-13: http://servlet.java.sun.com/javaone/sf2003/home/index.en.jsp We have booths reserved at both the above. We might also do the embedded east show in BOS Sep 15-18 http://esconline.com/boston/ So I'd encourage you all to try to have something to show at each of these. We can discuss providing some space in our booth when the time gets closer and the product gets "realer". Let me know if there is anything reasonable Systronix can do to help. For now, we'll provide some of the hardware blocks for you to wrap code around. Bruce |
|
From: James C. <ca...@vi...> - 2003-02-02 04:47:16
|
>To go from C/C++ to Java is not that hard for most programmers, I don't actually think this is the key Issue. I think it is the real-time nature of Embedded programming that puts people in a bit of a spin. We only need to look back at the Nutty Threading problems to understand that simulataneous processes are confusing. With the combinatorial problem of so many things going on at once, embedded programmers first instinct is to reduce the number of possible things that can be wrong, and a buggy High Level Language is usually the first thing to go stripping back to the assembly level to see what is wrong. >I think that muvium address this need brilliantly for the PIC community. >Muvium will enable an assembly-language-only PIC programmer to develop an >embedded solution in 100% PIC assembly language and then they can graphically >wrap it in a JAPL object, wire it to an Outpost and from there wire it to a >wide number of things from PLCs to backend enterprise systems. Bingo! - Got it in one Ted :-) But even better than this is they can use C! and even a C Library! in fact anything that can generate PIC assembly in function form without a dependency on some sort of OS can be used because my uvmjni technology scans for dependencies in a pseudo virtualisation of the PIC code and maps it all safely into a java wrapper while protecting my JavaOS. Even has a point and click wizard to make the mappings! It is the kind of thing with enough 'wow' factor to get PIC people interested in bringing code accross to the java world especially if they can plug it straight into something like the Embedlets container. This creates the opportunity to very quickly inherit vast quantities of legacy code to populate the JAPL layer of the Embedlets spec and involve an army of PIC developers to help with this part of the port is a very central theme to the muvium strategy of enhancing rather than replacing embedded skill sets. It might also give us a chance to get a really big win early which is critical for developing momentum. James Caska http://www.muvium.com 'Java Bred for Embedded' > -----Original Message----- > From: emb...@li... > [mailto:emb...@li...]On Behalf Of Ted > Kosan > Sent: Sunday, February 02, 2003 2:56 PM > To: emb...@li... > Subject: [Embedlets-developer] Re: Wiring tool versus Container > Infrastructure: WE NEED BOTH! > > > >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! > > Ok, Andrzej, I am with you. The concerns I had about graphic > Embedlet wiring > capabilities being marginalized have been addressed. > > > > I would, however, like to clarify a few of my earlier points: > > >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. [snip] > > My position here is that it is not the programming environment that is > constraining the number of normal Java developers that become > Embedded Java > programmers, it is their lack of computer interfacing and > low-level embedded > programming background. When Ajile and Sun had their Dancing > Robots contest > at JavaOne two years ago I (along with Jac) volunteered to spend some time > helping people program the robots. A real eye-opener for me was > that 95%+ of > the Java developers that came up to the booth were scared to > death to touch > these JStamp-based systems because the hardware was completely in > the open. > They were capable of programming the robots but the naked hardware really > intimidated most of them. We had to do a lot of hand holding and > re-assuring > that they were not going to blow anything up if they touched the > robots and > even then we ended up doing most of the 'touching' for them. > > I encounter a very similar situation when teaching Embedded Java > using TINI > with the Systronix 8x1 board. The ones that are already good > Java programmers > can program almost anything one wants in Java but as soon as you > encourage them > to do something like control a relay or read the frequency of a very low > frequency input signal, they are stopped cold because > electronics, computer > interfacing and embedded style programming are completely foreign areas to > them. > > So the constraint is the interfacing hardware and the specialized > programming > techniques involved in controlling it. > > > > >Chicken and egg syndrome Ted. Your argument holds only if > >there is a large selection of pre-built embedlets > >to choose from. > > > > 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 naove users will be able to wire? > > At least for my initial pet target market, I envision that the number of > Embedlets needed at first will be fairly small. The reason for > this is that > even though enterprises will eventually need sophisticated monitoring > capabilities, they are currently just getting started with this > effort and they > are not capable of handling anything more sophisticated than > reading simple > physical quantities like temperatures, pressures and switch states. A > relatively few well-chosen Embeldets, along with a clean way to submit > measurements to an enterprise system, will be more than enough to > get started > with. > > Success with a graphical wiring application that has access to > only a handful > of components is easily seen with the Lego mindstorms environment. This > environment contains a small, fix number of well-chosen > components and it has > done very well in the marketplace. > > So, a full-blown Embedlet market is not needed up front to get > started in most > areas and my pet target market was never dependent on such a market. > > > > > 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 initial embedlets, device drivers > >and communications adapters for all these platforms? > >You're not going to wire those at first.... > > I think that James and Bruce could add much to the discussion here. My > perspective is that it is going to take years for us to see anything even > approaching a significant number of these low-level programmers > migrating to > Java. Over at least the next 3 years I think the best we can > achieve is to > allow them to easily attach their legacy and current systems to a > network using > some technique that does not require them to program in Embedded Java. > > I think that muvium address this need brilliantly for the PIC community. > Muvium will enable an assembly-language-only PIC programmer to develop an > embedded solution in 100% PIC assembly language and then they can > graphically > wrap it in a JAPL object, wire it to an Outpost and from there > wire it to a > wide number of things from PLCs to backend enterprise systems. > > > 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 > > |
|
From: Christopher S. <cs...@oo...> - 2003-02-02 04:20:16
|
Ted, You're a passionate man on this topic! Personally, I agree that the graphical tools will be an essential part of the acceptance of Embedlets. There are numerous examples of successful graphical configuration and monitoring tools including schematic/PCB CAD and Enterprise Workflow tools. You can still make circuit boards by laying tape on acetate but why would you? It has been my experience as well that you can have the slickest and most thought-out technology on the planet, but if it doesn't flash and whirrr, nobody is interested. I am less insistent, however, that this project create the standards for GUI components. One of the premises of an open standard projects such as this is that we cannot predict what systems it will be required to connect to. This could include but not be limited to: Workstations (PC, Linux, MAC, Sun...), Web servers (JSP, ASP, .NET, J2EE, Perl...), Wireless devices (Palm, PocketPC, Cell...), Legacy MainFrame/Mini (AS400, IBM9000...). That being the case I would recommend: 1. We concentrate on the core Embedlet technology to let us quickly produce a standard with a demonstratable reference implementation. 2. We create a simple, flexible communication protocol that will accomodate any XML, TCP/IP capable system. 3. We create demonstration GUI based configuration and monitoring tools. At least a JavaBean/Swing component that can be used as a bsisi for extension. This, I have found from experience, is the 'easy' part as long as the underlying technology is simple and directly exposed as it is in XML. Chris -----Original Message----- From: emb...@li... [mailto:emb...@li...]On Behalf Of Ted Kosan Sent: Saturday, February 01, 2003 2:46 AM To: emb...@li... Subject: [Embedlets-developer] Wiring Tool, Legos, PLCs, PICs, etc. 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 ------------------------------------------------------- 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 |
|
From: Ted K. <tk...@ya...> - 2003-02-02 03:55:38
|
>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! Ok, Andrzej, I am with you. The concerns I had about graphic Embedlet wiring capabilities being marginalized have been addressed. I would, however, like to clarify a few of my earlier points: >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. [snip] My position here is that it is not the programming environment that is constraining the number of normal Java developers that become Embedded Java programmers, it is their lack of computer interfacing and low-level embedded programming background. When Ajile and Sun had their Dancing Robots contest at JavaOne two years ago I (along with Jac) volunteered to spend some time helping people program the robots. A real eye-opener for me was that 95%+ of the Java developers that came up to the booth were scared to death to touch these JStamp-based systems because the hardware was completely in the open. They were capable of programming the robots but the naked hardware really intimidated most of them. We had to do a lot of hand holding and re-assuring that they were not going to blow anything up if they touched the robots and even then we ended up doing most of the 'touching' for them. I encounter a very similar situation when teaching Embedded Java using TINI with the Systronix 8x1 board. The ones that are already good Java programmers can program almost anything one wants in Java but as soon as you encourage them to do something like control a relay or read the frequency of a very low frequency input signal, they are stopped cold because electronics, computer interfacing and embedded style programming are completely foreign areas to them. So the constraint is the interfacing hardware and the specialized programming techniques involved in controlling it. >Chicken and egg syndrome Ted. Your argument holds only if >there is a large selection of pre-built embedlets >to choose from. > > 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? At least for my initial pet target market, I envision that the number of Embedlets needed at first will be fairly small. The reason for this is that even though enterprises will eventually need sophisticated monitoring capabilities, they are currently just getting started with this effort and they are not capable of handling anything more sophisticated than reading simple physical quantities like temperatures, pressures and switch states. A relatively few well-chosen Embeldets, along with a clean way to submit measurements to an enterprise system, will be more than enough to get started with. Success with a graphical wiring application that has access to only a handful of components is easily seen with the Lego mindstorms environment. This environment contains a small, fix number of well-chosen components and it has done very well in the marketplace. So, a full-blown Embedlet market is not needed up front to get started in most areas and my pet target market was never dependent on such a market. > 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 initial embedlets, device drivers >and communications adapters for all these platforms? >You're not going to wire those at first.... I think that James and Bruce could add much to the discussion here. My perspective is that it is going to take years for us to see anything even approaching a significant number of these low-level programmers migrating to Java. Over at least the next 3 years I think the best we can achieve is to allow them to easily attach their legacy and current systems to a network using some technique that does not require them to program in Embedded Java. I think that muvium address this need brilliantly for the PIC community. Muvium will enable an assembly-language-only PIC programmer to develop an embedded solution in 100% PIC assembly language and then they can graphically wrap it in a JAPL object, wire it to an Outpost and from there wire it to a wide number of things from PLCs to backend enterprise systems. Ted __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |
|
From: James C. <ca...@vi...> - 2003-02-02 01:03:11
|
>Chicken and egg syndrome Ted. I have called it 'build it and they will come' syndrome in the past. We ignore the fact that one of the key reasons java took off in the first pl= ace is that SUN! provided a vast quantity of packages that solved hard proble= ms for java developers. I would argue that it is the packages that made java not the language. Su= n built the packages. Here we are in the situation where there are literally thousands of devic= es drivers for cork to write and thousands of embedlets to use that drivers = via JAPL or whatever and all this needs to happen before a wiring app can 'wi= re them together' without requiring someone to write and embedlet or even harder a JAPL device driver. I would argue that at the moment C has a bigger library than Java in embedded which is why it dominants. Almost nothing to do with the languag= e. Java however has the advantage that its library can go further.. ie it is inherintly more re-useable than C. The issue is that the C libraries are 80/20 libraries so are hard to slay. 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 10:49 AM > To: emb...@li... > Cc: tk...@ya... > Subject: [Embedlets-developer] Re: Wiring tool versus Container > Infrastructure: WE NEED BOTH! > > > 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 th= at > 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 Jav= a > > 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 prov= e > 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 t= hat > > 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 i= s > > 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 =93how d= o > > 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?=94 And the ruthless answer is =93Not very much=94. T= INIs 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 commerci= al > > success. > > Agreed. > > > The primary reason for this is that Enterprise Java developers have n= o > > where near the background needed to successfully deal with the Embedd= ed > > 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 primaril= y > > enterprise developers (including enterprise Java developers) is a fla= wed > > 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 a= nd > 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 framewor= k. > > What capabilities do Embedlets offer an > > Enterprise Java developer that normal Embedded Java does not offer th= em? > > 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 popul= ar. > > > Answer: =93Not much=94. Again, TINIs have been around for over 3 yea= rs 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. A= nd > 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/transpo= rt > 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 se= e > 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 instrumentati= on > 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 norm= al > > 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 t= he > 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 component= s > (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 =93most likely *initial* target ma= rket > > for graphically wired Embedlets=94 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 f= or > > 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=EFve users will be able to wire? > > > To say that Embedlets are only *for* solving problems in the enterpri= se > > space is just as suspect as Sun stating that Java was only *for* solv= ing > > 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 wha= t 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 wh= at > > 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 i= s > > growing at a snails pace and so it is going to be small for a very lo= ng > > time. > > See above comments. I think I've addressed this. > > > So, after working extremely hard for years to increase the size of th= e > > 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 wil= dly > > 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 v= ery > > 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 th= em > > 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 Embedle= ts > > 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 wir= ing > > capabilities, and then marketing these capabilities to any and > all markets > > that could potentially use them, is *equally* as important for Embedl= ets > > 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 the= y > 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 t= o > 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 > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld =3D Something 2 See! > http://www.vasoftware.com > _______________________________________________ > Embedlets-developer mailing list > Emb...@li... > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > > |
11 messages has been excluded from this view by a project administrator.
