Volume Number: 14 (1998)
Issue Number: 7
Column Tag: Viewpoint

July 1998 Viewpoint

by Eric Gundrum, editor_emeritus@mactech.com

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.