Re the PC Week article, this is just my casual opinion about the Oracle's (NCI) NC/OS, with no substantive facts to base it on:
I think the NCI 1st generation NC is not intended to provide very much functionality, probably consisting mainly of a browser with a smartcard startup capability. In particular, the browser obviously can be used to emulate a typical IBM dumb terminal, making it immediately useful in mainframe applications. This enabled Ellison to show NC progress, defined by 1st generation NC's being produced by numerous manufacturers, and apparently they will enjoy a reasonable amount of sales because of the huge number of replacement and new dumb terminal requirements that still are needed.
As far a Java goes, and without any doubt whatsoever as far as legacy C/C++, Fortran, COBOL, and even embedded SQL (the guts of traditional client/server architecture), everything is under development, including Oracle8's ability to dish up all these services. Oracle and other partners have only now completed specifying embedded SQL in Java, called JSQL. The full implementation of Data Cartridges, needed to wrap legacy applications for access through Java, will take up to two years.
Does this mean that NCI is rethinking developing NC/OS 2 using VxWorks, and sticking with NC/OS 1? Absolutely not, there isn't anything there to stick to. All the reasons for moving to VxWorks to begin with still exist, and probably lots more.
What seems to be happening is that a complete, industrial solution to the NC is proving difficult and time-consuming, with 90% of the difficulty on the server side. I don't think the PC Week article, nor anything else that has surfaced, has altered our view of the situation one iota. I believe NC/OS 2 will appear in 1998, prior to a full server solution, but with the capability of providing enhanced functionality compared to NC/OS 1. Namely, better Java processing, specifically JSQL and true dynamic access/quick compile of Java Applets, and probably better system administration relative to the server. Of course, this assumes that JavaSoft works out some of the hot problems sooner rather than later, but this should be realistic. Also, NC/OS 2 will be available and/or portable to many more hardware platforms.
My guess is what will not debut along with NC/OS 2 is the fully implemented Network Computer Architecture on the server. This is a major problem for companies, because many cannot replace PCs without being able to execute legacy client/server, not just mainframe, applications. Pure Java custom applications will take awhile before they justify NCs. Adequate Pure Java OTS software should be available early in 1998; isn't some available now?
As far as maintaining backward compatibility with NC/OS 1, it should be easy to carry along compatibility because there probably isn't much to be compatible with.
Another comment about JavaOS problems. All the problems I have heard about are show-stoppers if and only if the application is deeply embedded. None of the problems I have heard about need to be fixed perfectly to have an acceptable NC. Since when do we demand perfection, or much robustness at all, when selling into the PC paradigm? Neither Microsoft nor Oracle has worried much about robustness. Stability comes in due course, along with enhancements. In fact, the best encouragement to buy enhancements is the belief that the upgraded system might be more stable.
This is not a joke. Humans are both forgiving and able to counter the effect of bugs, so the software industry gives them all they can handle. (Economists will recognize the underlying principle at work.) It is not with the NC that Java works unacceptably, the serious problems only limit Java's use where failure is unacceptable - deeply embedded EIDs.
Let me serve up an example I read about just today. A Java-capable browser was programmed using JavaScript to display a clock, changing each second. After awhile the program blew up for lack of memory. The quasi-programmer discovered that the villain was that the clock object was created anew with every display without removing prior clock objects, eventually using up all available memory causing the crash. Memory leaks in C/C++ are common, and nowadays usually are found by use of special inspection tools well before even testing the program. But Java is immature in this regard, caused by the automatic garbage collection designed into the language.
So, how did the quasi-programmer fix the correctly diagnosed clock problem? With a straight face (I discerned from the way the example was written), the fix was to alter the clock to display time change every minute instead of every second. This made it improbable that the program would crash while being executed. I guess this isn't so bad. Once humans learn that clock-showing programs shouldn't be left active too long, they will simply adjust to shorter execution times.
To summarize:
(1) There is no reason to believe that NC/OS 2 is not on track for 1998 production in NC's. (2) There is absolutely no reason to believe that NC/OS 1 is something NCI will want to keep around. (3) NC server capability for everything except legacy client/server applications will probably be available in 1998. This will be satisfactory for consumers (since there are no legacy client/server applications) and for new custom, corporate applications, but less satisfactory for companies. (4) Probably acceptable Java desktop applications will available for most common functions like word processing, email, spreadsheet, scheduler, etc. by 1998 if not before. When will Microsoft port of Excel and Word to Java? When will they do it without Windows-specific enhancements, if ever? Answer: Not until MSFT has to, but they will not repeat the Lotus and Word Perfect mistake of missing a market, will they? (5) NC server capability fully implementing NCI's Network Computing Architecture probably will not be available until well into 1999.
Allen |