Welcome to Orcmid's Lair, the playground for family connections, pastimes, and scholarly vocation -- the collected professional and recreational work of Dennis E. Hamilton

 

Rich Client, Poor Client, Smart Client, Web Client

Joel on Software - How Microsoft Lost the API War.  Joel Spolsky outdoes himself (and he'll do it again) in explaining what happened to the developer world and how the Windows API may have become irrelevant.  This is a big deal, because the Windows API is as important to developers and Microsoft as the Wintel BIOS is to PC makers and Microsoft.

Here's how it looks to me:

• There now are more APIs, of different kinds at different levels, increasing the platform's appeal.
• For web-distributed applications, more has been done to ensure that Microsoft platforms fit naturally on one or both sides of those connections than for any alternative.
• It doesn't matter which toolcraft prevails for choreographing the desktop user interface of web-serviced applications: It will be supported on Windows.

Here's how I see preservation of Microsoft platforms as the integrative technology of choice.  [disclosure: My firm is a member of the Microsoft Empower ISV Program.  On Wednesday, my four-pound DVD starter kit of all-the-software-you-can-eat-for-a-year arrived.]

Protecting the Cycle of Demand.  Joel, in discussing what he calls the Raymond Chen [and here] model, acknowledges the tremendous effort that Microsoft has invested in supporting third-party legacy applications.  Microsoft works diligently to make OS upgrades as painless for customers as possible;  the company is very attentive to those people who buy the computer that has the operating system that runs the applications that are developed on the operating system that runs on computers that people buy.  Microsoft owns the tollbooth (and the pit stops) on that particular Möbius-surfaced gerbil raceway and the ticket onto this ride for developers has been the Windows API (along with its companions, the Platform SDK and application-deployment model, all available at no cost on-line).  Nothing illustrates the commitment to grandfather working applications better than the current desperation to put Windows XP SP2 out there and have it be installed successfully by everyone who tries it, creating a buzz that encourages nearly everyone else to try it too.

The Web, as in Freedom.  Joel sees a dramatic change now that the ideal means for application deployment is the web.  The competing protocol of choice is now HTTP, an open industry standard for connecting users and applications and services across platforms using the Internet.  Now the client is your web browser, and the application is somewhere else.  Anywhere else.  I'm operating with that model this moment as I create this blog entry using www.blogger.com.

Wallpapering the Usability Divide.  This is not a perfect arrangement because of browser incompatibilities (and the annoying tendency of developers to QA against only one particular browser).  Along with that, browser-based applications can be pretty intrusive, and even when that is tolerated, browser usability is not that same seamless application experience found with well-crafted desktop-application surfaces.  Joel provides a nice recap of the dissonance with your Aunt Tilly's desktop:

But there's a price to pay in the smoothness of the user interface. Here are a few examples of things you can't really do well in a web application:

1. Create a fast drawing program
2. Build a real-time spell checker with wavy red underlines
3. Warn users that they are going to lose their work if they hit the close box of the browser
4. Update a small part of the display based on a change that the user makes without a full round trip to the server
5. Create a fast keyboard-driven interface that doesn't require the mouse
6. Let people continue working when they are not connected to the Internet

to which I would add being able to work in multiple applications at once and blend between them while also providing for full accessibility.  I have never considered substituting Hotmail and web-based distributed-learning applications for the fat-client Outlook and FirstClass on my desktop.  I will be happier when I can operate my blogs from the desktop and not the browser.

Meet the New Game, Just Like the Old Game?  It is not so clear to me that Microsoft is changing the game.  With .NET, there is a new integration model that works with web-deployment and smartness on the client.  In addition, the raw platform and a good chunk of the API has been contributed in public, freely-available specifications through standards processes of ECMA International.  Two major tests of this new agility are GNU dot Net and the Mono project.  Mono is coming along nicely with release 1.0, now sponsored by Novell, in beta.  This suggests that Microsoft's offering of the baseline .NET facilities as a basis for heterogeneous, cross-platform distributed applications is serious.  There is corresponding promotion of XML and Web Services that support platform-independent ownership and preservation of distributed data.  That's effectively a new API, one based on XML for presentation data units (in the old Open Systems Interconnection -- OSI -- Model sense of presentation) and for protocol data units in the Web Services protocol stack. 

Here a Stack, There a Stack, Everywhere a Stack, Stack.  "Stack" is increasingly showing up in the language of Microsofties, and the relationship to OSI models seems to be no accident.  It is, of course, completely possible, permissible, and encouraged to build proprietary layers atop an open stack and to wrap proprietary infrastructure as open-system access points.  It is important to realize that Web Services (and XML) are for application-to-application communication and the stack provides for thin-client, client-server, peer-to-peer, component substitution, service-oriented architectures, distributed security, and who yet knows what other forms of distributed operation.  On Microsoft platforms, .NET and the WS stack will be bolted in everywhere, with application access mediated by, you-guessed it, interfaces to objects supplied via .NET library classes.

Counting APIs.  Beside the Windows API, we now have two more interface stacks:  The .NET API on the platform and the XML/Web Services stack for cross-platform operation.  Although .NET is still evolving and transforming (as are Web Service specifications and implementations) the picture is fairly clear.  If you are in a position to use Microsoft libraries, then you will have their strong on-platform support libraries for offering and accessing Web Services.

Is It a Good Thing?  It seems to me that there is more for Microsoft to gain in this approach than anything there is to loose.  Their own developers require this capability in delivery of applications and services.  I don't think external developers will find anything unwelcome here.  There are now more layers of defined interface around which Microsoft may extend their platform reach, and third parties can do the same.  With the .NET ability to easily define and substitute components both above and below the Microsoft-defined integration points, there is less reason to fear becoming captive to a platform-exclusive point-of-view.

Are You a Good Witch or a Bad Witch?  While it may seem that these open interfaces don't bind developers so close to the Microsoft platform as before, it is definitely easier to develop and confirm applications using Microsoft client and server platforms.  And on any platform, making sure that there is interoperability with the thorny cases of Microsoft's Web Service implementations will matter.  In addition, developers will find it easier to integrate alien servers (running J2EE, say) and mainframe legacies into Microsoft platform solutions.  I would say that Microsoft has done as much as anyone to enable platform interoperability and preservation of application code and design portability.  They're not going to do it for us, and they're also not in the way.  I like their confidence that this is a valuable way to compete.

In the Eyes of the Beholder.  I see the interoperability features as evidence of Microsoft's eagerness to extend its platform's reach and availability in a world of competing user agents and service sources.  I've ignored competing approaches to user-interface crafting and visual-development of applications.  There isn't any experience to suggest that Microsoft will be at any disadvantage in those areas.

Listening to:

Duke Ellington Ellington at Newport (1956) Complete double CD, Columbia (1956, 1982, 1999).  My high-school chum Ron Lougheed gave me my first LP of this concert performance, and I wore it out before the sixties got very far.  It is great to have this fine expanded compilation.

posted by orcmid at 6/19/2004 03:15:56 PM