Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : Wind River going up, up, up! -- Ignore unavailable to you. Want to Upgrade?

To: James Connolly who wrote (7737)	5/5/2000 7:03:00 PM
From: voop	Respond to of 10309

biz.yahoo.com JC Suggest you post tornado white paper on G and K thread Voop

To: James Connolly who wrote (7737)	5/6/2000 2:14:00 PM
From: James Connolly	Respond to of 10309

The white paper gives an excellent insight into WIND and the wireless Internet. In particular the Java connection and WIND's view of Symbian. On the face of it, it looks like WIND has a well thought out strategy going forward. WIND gets more interesting by the day !!! Regards JC. Java. "Sun has worked closely with NTTDoCoMo in Japan, as well as leading mobile phone OEMs such as Motorola, Siemens and Nokia, to develop a configuration specification for mobile phones. The configuration specification is known as the Connected, Limited Device Configuration (CLDC), and the associated profile is known as the Mobile Information Device (MID) Profile. The European Telecommunications Standards Institute (ETSI) is watching closely. It is likely that the specification will become part of the Mobile Station Application Execution Environment (MExE) specification for application delivery on next generation mobile terminals. The intent of the MID Profile was to fine-tune the API?s requirement to support Java on handsets, pagers, and PDAs. The MID Profile was based on the JavaPhone, Java Telephony API, and Mobile Network Computer Reference (MNCR) specifications, which were developed for the PersonalJava? platform, and thus too large. The new spec better represents the requirements for "state of the art" wireless APIs, such as a display toolkit for limited size and depth displays, user input methods, persistent storage, messaging, networking, security, and wireless telephony. Mobile phone OEMs see the potential of using Java to access millions of mobile Internet applications through the J2ME architecture. It lets them leverage their manufacturing capability, rather than trying to rally application developers around a proprietary architecture. The attraction of the KVM is that it is scalable to both high and low-end phones. It also provides a means to build and securely deploy new applications and dynamic, interactive content to cell phones and mobile devices" Symbian. The Consortium?s Fallacy In the wireless industry, in-house operating systems have proliferated from the early days of the voice-only mobile phone. Rather than rely on commercial off-the-shelf solutions (often targeted at broad horizontal real-time applications), in-house operating systems have been tightly focused on the task at hand. While it was necessary in the beginning, companies have relied too long on in-house development ? a waste of resources and lost time-to-market. In-house solutions have proven ill-suited to the changing requirements and new processor architectures that have evolved since 1992. This has resulted in a multitude of in-house designs and incompatible code bases to support. Some of the larger OEMs have had over a dozen in-house kernels to support. Many have realized that it is time for this approach to end. It is difficult to tell if the mobile operating system consortium launched two years ago was born from a management reaction to the software crisis, if it was a plan to create third-party developer momentum, or if it was a marketing campaign to hype market awareness. While the best technology does not always win in the market, the consortium approach is often one of the worst ways to go forward. The consortium?s solution falls well short of meeting the mobile Internet?s requirements in the critical areas of real-time deterministic performance and small footprint. Perhaps the consortium believed that next generation mobile handsets would have greater application requirements and need the support of third party developers like desktop programmers. In this case, a good API and a third-party developer program would naturally have been attractive. Unfortunately, the need for third party developers is limited in next generation devices, because the mobile Internet business model depends on content and connectivity via technologies such as WAP and K-Java, not proprietary third-party applications. The Microsoft and Netscape browser war made this point clear. What OEMs need is not an organizer operating system, but a core real-time foundation and solid development tools so that they and their third-party partners can build next generation devices ? a whole range of them ? quickly and easily. A Java virtual machine on these devices will allow third party developers to create a wealth of mobile applications. On reflection, with regard to why the mobile operation system consortium was born, the marketing ploy seems the most likely explanation. And in terms of raising awareness of mobile Internet opportunities, its efforts have paid off.

To: James Connolly who wrote (7737)	5/6/2000 3:08:00 PM
From: lkj	Read Replies (2) \| Respond to of 10309

Hi James, Just read WRS' White Paper on Mobile Internet. I think it was a very well written paper. Here are a few thoughts: In referencing to a dual-CPU design, WRS is targeting Qualcomm's next generation ASICs. It correctly pointed out WRS' advantage in 2.5/3G handset designs: * Superior development platform. * Tight integrations of data/voice/postioning/multimeda. Important for time-to-market and power consumption. * Processing broadband data, this is when a CDMA modem seem more like a DSL modem. (Who is better than WRS in IP?) Again, this is targeting directly at all of the features in Qualcomm's upcoming ASICs. VxWorks will be sitting in a lot of these 3G base stations or IP gateways. I wonder if WRS can play some tricks to make the data interface between the base station and handsets more efficient? (Can you see a TMS for cellular base station? I can.) What I disagree with the paper is on Java. If Java (or ASP as Allen has been pointing out) is the way that every application will be, Palm OS, EPOC, and CE will loose all of their advantages. But I don't think Java and ASP will happen in a big way for mobile computers, at least not in the speed that we would like. This is another reason why Qualcomm went with a dual CPU design, one for a communications OS: RTOS, the other for an application OS: CE, EPOC, or Palm OS. I think Qualcomm did the right thing by putting two cores in there, because the application OS will definitely crash, and potentially often. As I wrote earlier, I see a simple mobile platform and a PDA-like mobile platform. VxWorks should work for the former, but for the latter, it needs to partner with Palm OS, which is very likely, especially for these dual chip designs from Qualcomm. Overall, I like what I read, and I like the direction WRS is moving to. Thank you for giving the link on the White Paper. Khan