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:
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: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.
"I will be happier when I can operate my blogs from the desktop and not the browser."
I use BlogJet - www.blogjet.com. More accurately, I'm currently using a trial version (I was part of the free beta program) and trying to decide whether to spend $20 on it.
Thanks Mike. You've given me a great pointer. BlogJet is exactly the kind of functionality I want on my desktop. I think this is the sort of thing that people who take the easy sign-up for Blogger should have for getting the rest of the way.
I'm not going to try it because the temptation to reverse-engineer would be too great. I will just work from the BlogJet (Content-type charset Cyrillic) web page as a great source of requirements.
Meanwhile, I want to find a way to disintermediate my blog (that is, not have it be archived, generated and posted by a third-party service), and that will take a little more work. I think the trick may be to add the Blogger API or something comparable to my localhost development site (IIS on XP Pro), maybe even FrontPage extensions. Then I can look at the challenge of keeping synchronized with comments and edits that are coming directly onto the hosted site -- the ultimate challenge for loose coupling of blended operations.
And here's an example of why I want disintermediation. When I posted my comment, above, I created an <a>-element so that the link to BlogJet would be easy to follow. I used href="http://blogjet.com". What Blogger inserted was a link that passes through the Blogger site and traces the reference. That is on my page, on my host site, and they are tracking links made by my commenters. I don't know what the paternalistic point of that is, but it cheeses me off no end. I want to go over and do a guest page on causticTech just to let off steam!Post a Comment