Volume Number: 13 (1997)
Issue Number: 7
Column Tag: Viewpoint
by Eric Gundrum
WWDC is over, and I've just spent a full week listening to the official Apple message. Many weeks may have passed by the time you read this article, but my mind is still hashing out the things I heard just a few days ago. I must admit, I attended WWDC 1997 with pretty low expectations. Last year attendees had Copland forced on them as the only possible future for Macintosh development. This year was very different; Apple listened to developers and offered us several options for our future development. In fact, they even encouraged us to send our comments to rhapsody-dev-feedback@apple.com. I am pleased with how well Apple handled the conference.
Since Apple and NeXT's merger, I have heard many Macintosh developers express concern that their skills programming the Macintosh will be obsolete. After all, Rhapsody replaces the Mac Toolbox with something new, code named Yellow Box. (Yellow Box is the combination of OPENSTEP and key Apple technologies.) The APIs to Yellow Box is dramatically different from the Macintosh Toolbox. However, what makes a good programmer is not merely knowledge of one system's API. Good programming is about bringing organization to a complex situation, providing a simple solution to solve a complex problem, and identifying what a user wants. Our skills as programmers rely more heavily on our ability to organize the problem and solution than they do on knowledge of any particular API. Anyone can look up API calls in a manual, but it takes an experienced programmer to know what routines to look for and how to connect them together to make a meaningful application.
Some of our greatest skills as Macintosh programmers are our abilities to design meaningful interfaces to help users solve complex problems. These skills can translate to any platform. (One need try only a few Windows applications to see how rare are these skills.) Even though we will need to learn a new programming environment, it also presents a fresh start for new and non-Macintosh programmers to join us. Those who have the high quality skills we have come to expect of Macintosh Progrmmers will do well; the others...well, who knows. Rhapsody offers many new opportunities to build more powerful and interesting tools; I very much look forward to using those tools, and creating some myself.
Apple had many strong presentations about the future of MacOS 8. They presented a clear schedule for delivering significant upgrades well into 1999. They presented several new technologies being developed for MacOS 8. Most important, they told us Yellow Box would be made to run on MacOS 8 in addition to running on Rhapsody.
Apple is realistic about the addoption rate of Rhapsody; they expect 4-5 million Rhapsody users by mid 1999. That is a far cry from the current 27 million MacOS 7 users. Many developers have complained that they don't want to have to write their applications twice: once to support Rhapsody and a rewrite to support MacOS 8. Apple has responded by porting the Yellow Box APIs to MacOS 8. This will allow developers to use one API to write their code once and have it run on all Macintosh platforms.
This single API approach is especially important given how much we all (developers and Apple) rely on MacOS 8 for our bread and butter now and for the future. Enabling developers to take avantage of Yellow Box to build applications faster than ever before and deploy them on MacOS 8 as well as Rhapsody makes it that much more compelling for us to begin our Rhapsody development as soon as possible.
Many Macintosh developers have been dreaming for some time of entering the Windows software market. We see analists' numbers that generally have an extra zero or two at the end as compared to our own Macintosh market. (People tend to forget that those extra zeros apply to costs as well as revenues, and to the number of competitors.) I've talked with many developers struggling to deal with porting their software to other platforms. Rhapsody -- or more specifically Yellow Box -- offers a very different approach. Unlike Java, Yellow Box today offers a much more mature solution to the multiplatform software problem. With so many competing implementations, Java only dreams of solving the problem of write your software once, and deploy it anywhere. With Apple controlling all implementations, Yellow Box is actually delivering it.
Apple has promissed Yellow Box compatability in at least four flavors: Rhapsody for PowerPC, Rhapsody for Intel, Yellow Box for MacOS, Yellow Box for Win32 (that is, NT and 9x). Additionally, there are strong rumors that Yellow Box will also be available for Solaris and HP unix. That is a pretty broad market. The goal is that we developers can write our software to one API and merely recompile for each target platform. Apple is even working on multiplatform delivery mechanisms. In reality there are subtle differences between platforms that require some additioanl tweaks, but Apple is helping even there. For example, there is a specific nib file (resource fork) for each target platform, allowing platform-specific interface changes to override the platform's default behavior.
Another reason to develop for Yellow Box is the completeness of the application framework. We have had frameworks for Macintosh for many years now, but none fully hide the need to know the underlying Mac Toolbox. Yellow Box is the toolbox. When building an Yellow Box application, so much of the user interface code is already written, we developers are free to ship sooner or spend time adding more features.
Rhapsody is not all peaches and cream. There are some holes; the poor networking support is the biggest. Between Apple's presentations and my conversations in the halls of WWDC, it is clear that Apple still doesn't understand how the Internet is changing; their "strategy" is limited to web content development and deployment. They seem to be ignoring many other areas including communications, collaboration and commerce. For example, Yellow Box does not provide any foundation classes for using common Internet protocols such as HTTP or FTP. It doesn't even provide a foundation class for basic IP networking. This means that every network-savvy Yellow Box application must use platform-specific network code. A Rhapsody application will use Rhapsody's version of BSD sockets, a MacOS application will use OpenTransport streams and a Wintel application will use WinSock. Given that networking is the fastest growing segment of the software industry, it seems absurd that Apple does not provide a network abstraction layer in Yellow Box as they have for the user interface.
This networking issue also raises the question of why Apple is using sockets instead of streams. Everyone I spoke with has made a strong argument for streams being a more flexible and generally superior architecture. When Apple asked us all to move our network code to OpenTransport (streams), they said it was a technology for the furture. Streams provides standard APIs at all levels, allowing developers to write code to adjust the contents of the network at the level that makes sense for their software. Some developers argued that Apple should develop a sockets interface to make porting code to other platforms easier. Apple answered that sockets could easily be implemented on top of streams, and some third parties offered libraries doing exactly that. It is very hard to go the other way because sockets implementations really define only the highest level API. The underpinings are specific to each platform.
Not only is it odd that Apple seems to have ignored their original reasons for moving all developers to a streams implementation, but Apple already has most of the streams code for Rhapsody, including complete network stacks for AppleTalk, IP, IPX, and TokenTalk. Instead, they are porting the NeXTSTEP sockets code and adding the AIX AppleTalk sockets code; then they have to find a way to make Blue Box's OpenTransport (streams) work on top of this. Many WWDC attendees asked Apple how they intended to solve specific, difficult problems with this scenario. Apple's most common answer was "Hm, we hadn't thought of that. That's is a hard problem, but we're sure we can solve it when we get to it." To Apple's credit, they repeatedly took some harsh critism from attendees, and they appeared to really listen. Hopefully they got the mesage that they should reevaluate the technical merits of choosing sockets over streams so we can have a networking architecture that can grow with the rest of the platform.
