Jul 98 Viewpoint
Volume Number: 14
Issue Number: 7
Column Tag: Viewpoint
July 1998 Viewpoint
by Eric Gundrum, editor_emeritus@mactech.com
WWDC, What Apple Has Been Up To
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 1998 with pretty low expectations. Last year attendees
had Rhapsody 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. I am pleased with how well Apple handled the
conference.
You may recall I wrote those same words immediately following last year's WWDC. As I
was preparing this column, I thought I'd review what I wrote last year. I was quite
surprised to find that the opening paragraphs of last year's column so accurately
reflected my feelings about this year's WWDC.
Every year developers come away from WWDC excited about Apple's new strategies and
technologies. Why should this WWDC be any different? This is the third year in a row
that Apple has given us a whole new operating system strategy. So what's different
about this year's conference?
Mac OS X, A Peak at the Future
By now you've probably read all about Apple's new OS strategy. Rather than give us yet
another OS, Apple has mixed the best technologies of Mac OS, Rhapsody, Java and even a
little of Copland. I am much more comfortable with these evolutionary changes than
with last year's OS revolution.
In a nutshell, Apple is offering a way for existing applications to live side-by-side
with Yellow Box applications running on the Rhapsody Kernel. Similarly, Java and
BSD Unix programs also should work in Mac OS X. Existing Mac OS software will run
in a Blue Box without any of the Rhapsody Kernel benefits. To be an equal player in the
Rhapsody world, existing applications must be recompiled to work with the Carbon
Toolbox, a subset of the existing Mac Toolbox with some additions. Because Carbon is
only a subset, some additional coding will be required for most applications. The work
should be minimal; much like the transition from 68K to PowerPC. The benefits of
protected address spaces alone will likely save developers more time tracing memory
errors than it will take us to rewrite the portions of our applications that rely on
problematic APIs.
Apple will not release Carbon until sometime next year, but most of the necessary
APIs are available today for applications running under Mac OS 7.5.5 and later.
Developers can clean up their applications now and the applications should run in Mac
OS X without further changes. The details are available from Apple's web site, and
probably will appear in a future MacTech article. From what I've reviewed of the
changes, most represent removing reliance on obsolete APIs (such as those superseded
by System 7 improvements) and failed technologies (such as PowerTalk). Developers
today can start preparing their applications to take full advantage of Mac OS X, and
they will get cleaner running applications as a bonus.
The developers that have the greatest challenge are those who provide the extensions
that we use to personalize our computers. As of WWDC there was no equivalent to the
current extensions mechanism. Instead, we can extend some behaviors of Mac OS X
using the Appearance Manager, drivers and faceless background applications. These
should cover the majority of what programmers do today with extensions, and they are
more stable mechanisms than the trap patches we live with now. However, these new
mechanisms are not quite as flexible as patching traps, making it a bit more difficult
for developers to release their creativity on the Mac OS. As I left the conference, there
was a good chance that the Apple engineers, together with some experienced extensions
developers were going to develop a clean, safe mechanism to let us hook in and provide
new, unimagined extensions. I wish them luck.
A Future For Yellow Box?
The reasons to build in Yellow Box are not quite so compelling any more. Apple did not
include Yellow Box in any of their keynote presentations, making many developers
think the technology was canceled. However, Apple claims it is alive and well, and that
Yellow Box is a strong environment for building new and multi-platform applications.
This suggests to me that Apple might want to migrate developers to Yellow Box as the
future Toolbox of Mac OS development, but Apple did not make that message very clear.
Compound that with Apple's statement that Rhapsody for Intel will not be revised
beyond version 1.0, and the future of Yellow Box becomes even less clear.
Maybe Apple is playing a game of wait-and-see: if enough products start to take
advantage of Yellow Box, Apple will continue its development. On the other hand, our
industry is pouring a lot of resources into making Java the multi-platform
development environment of choice. With Apple's directing most resources to Mac OS
technologies and substantial resources to Java, Yellow Box may not have such a strong
future. If Apple can finally catch up their Java to the same version as the rest of the
industry, Java will likely become the preferred environment for new development.
While we wait to see how this shakes out in the next year, we can concentrate on some
very interesting new Mac OS technologies just around the corner.
Extending Our Current OS
Apple appears to be listening to developers like never before. They heard our
complaints about the forced transition to Yellow Box and gave us Carbon. Apparently
they also heard our requests for certain Mac OS-based technologies; they have given us
services we've been requesting for years.
One such technology is the new Window Manager including OS support for floating
windows. Instead of developers having to muck around with an application's window
list or other private OS data structures, Apple is giving us an API to identify which
layer our windows reside in and the OS will manage window ordering and appearance
for us. The new Window Manager contains many more useful services reminiscent of
Copland.
Navigation Services is another new technology developers can begin using today. Nav
Services is a non-modal and extensible replacement for the decrepit Standard File
package. I've not look closely enough at the APIs, but I'm hoping that it also is
replaceable. In the past developers have offered significant improvements on Standard
File. I'd hate for Apple to cut out their market and eliminate the benefits of their
products. As a user I want to choose the file navigation interface that works best for
me. With Nav Services Apple has defined a standard interface. Now they should let
anyone plug in an alternative if that is what the user wants.
Subwoofer is back in the form of URLAccess. With a very few simple API calls, any
application now can do FTP and HTTP uploads and downloads. Imagine that your product
can post user registration information automatically using a few simple calls. Best of
all, the URLAccess technology is fully extensible; developers can write new modules
for their favorite protocols and just drop them in. Hopefully Apple will also extend the
list of protocols. I'd very much like to see at least SMTP Send support in the initial
release.
After a very long sabbatical, the keychain is back. No longer will users have to
remember all those passwords to AppleShare servers, FTP servers, or any other
services requiring passwords. With a few simple API calls, we developers can look in
the keychain for the password information instead of asking the user. The keychain can
store anything the developer wants to put in it. As presented at the conference, the
keychain has a long way to go to become a mature service, but I'd rather have a little
bit now, than wait another several years for Apple to reimplement all of PowerTalk.
What's missing: the keychain does not yet offer a standard, secure passphrase dialog to
be used by all applications, nor does the keychain offer any protections against one
application snooping the data inserted by another. In time I expect Apple with plug
these holes.
In an effort to migrate the Mac from AppleTalk to TCP/IP, Apple is providing
system-level services for registering and locating resources on any network,
including TCP/IP. This technology has been a long time coming. Apple will be providing
a simple API for applications to register their services on the network, and for other
applications to find them. Soon users will be able to truly browse the Internet to see
what services are offered instead of having to know the magic URL to get somewhere.
These are just a few of the new services becoming available in the next few releases of
Mac OS. Apple presented several others I don't have space to list. You can bet MacTech
will be covering them in articles as fast as we can get the details out of Apple.
A Blemished Apple
The one technology that had developers in the biggest uproar was Apple's claim to be
removing support for OpenTransport Streams from Mac OS X. This was announced even
while Apple presented one of the most clear and useful sessions ever on using OT
Streams. Apple publicly argues that OT streams have not been widely adopted, and they
claim they can provide sufficient functionality in Mac OS X using the BSD Networking
Stack. (In case you don't know the history, XTI Streams, on which OT is based, were
developed more than ten years ago to cleanly provide extensible networking that could
not be had with the BSD Stack.)
Unfortunately the Apple Rhapsody networking group is in a tough spot. One choice they
have is to move Rhapsody to Streams, but then they have to rewrite all their
Rhapsody-based networking services such as NetInfo, Telnet, FTP and others. The
other choice is to try to shim the OpenTransport client APIs onto the BSD Stack. This
later choice eliminates the API calls used by products which provide low-level
networks services such as PPP, secure (encrypted) networking, multi-homing,
software routing and others. Rhapsody provides some of these services, but third
parties will not be able to replace them with alternative services. (Such replacement
of these services requires recompiling the OS kernel; we can't have users doing that.)
Developers made very compelling arguments for Apple to stick with streams and not
step backwards to the days when every application contained its own networking stack.
Unfortunately for Apple that means they may have to rewrite some of their own
networked Rhapsody applications, because those applications did not use the public
APIs as the rest of us must. I'd rather see Apple clean up their own mess than force
developers into it. I'll even accept a significant delay in the release of all those
Rhapsody-based services. 20 million Mac OS users won't mind waiting an extra six
months for NetInfo and the like; it's the core OS we want. Apple promised they would
revisit this decision. I hope they carefully consider how their choice will affect the
next ten years of Macintosh networking; getting this far has been pretty painful.
In nearly all other areas Apple has demonstrated their willingness to listen to
developers, providing us with some very compelling technologies I and others are
anxious to take advantage of. Where networking is concerned, Apple seems to have made
their decisions without having accurate information about the importance of this
technology to developers and our users; we have now provided them with that
information. I am confident that once Apple reconsiders their decision to remove
streams support that they will not ignore such an important core OS technology. In
fact, I encourage developers interested in networking to look at Apple's newly released
OpenTransport documentation: Inside Macintosh: Networking with Open Transport and
OT Advanced Client Programming. These two volumes represent significant
improvements over what was previously available, allowing developers to write
serious network-savvy code with a lot less effort. Apple has given us the tools to make
the Mac the premier platform on the Internet; it's up to us developers to write the code
to keep it there.