Jul 97 Viewpoint
Volume Number: 13
Issue Number: 7
Column Tag: Viewpoint
July 1997 Viewpoint
by Eric Gundrum
Reality Distortion Field... Engage
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.
Rhapsody Does Not Make Obsolete Programmer's Abilities
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.
MacOS 8 is Alive and Well
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.
Rhapsody Provides Compelling New Opportunities
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.
Still Some Holes in Rhapsody
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.