Category Archives: .net

Windows Phone 8 will run Windows 8, with Silverlight centre stage?

More information on Windows 8 is leaking out now; and it gives some clues about how Microsoft intends to make sense of its two device platforms, Windows tablets and Windows Phone.

Microsoft held back from making its Windows Phone 7 OS available on tablets, which is why most of the numerous tablets being pushed out to compete with Apple run Google Android, and a few of them Windows 7 with its excessive power requirements and a user interface poorly designed for touch control.

Now the strong rumour is that Windows 8 supports two user interfaces, one that is tile-based like Windows Phone 7, and another that is designed for PCs.

In other words, rather than continuing with the Windows Phone 7 OS which is built on Windows CE, Microsoft will build a new version of the Windows Phone 7 UI on top of full Windows.

My further assumption is that Silverlight apps will still run on the new OS, providing continuity with Windows Phone 7 which uses Silverlight or XNA, both based on .NET, for its application platform.

Silverlight might also be used as the platform for apps delivered by the new Windows app store. This is Paul Thurrott, though reported as rumour:

Windows 8 will also include a new app model codenamed Jupiter that will target a new Windows Marketplace app store. The app store will provide access to new, Silverlight based "immersive" applications that are deployed as AppX packages (.appx). The Windows and Office teams are betting very heavily on this new app type, according to my source, and development has already begun using a beta version of Visual Studio 2012. These apps can be written in C#, Visual Basic, and even C++.

We do know that Silverlight 5 supports full platform invoke of native code, a feature which tends to support the idea that it is becoming a key runtime for Windows.

Let me speculate a little further. Imagine you are Adobe, for example, which has said it will deliver the Flash runtime for Windows Phone. Although it competes with Silverlight to some extent, Microsoft needs to tick the Flash box for Windows Phone. But why would Adobe want to invest in Flash for Windows CE, when this OS is not going to be used for Windows Phone 8 and it will have to write new code? I will not be surprised if we hear that Flash is now not coming until Windows Phone 8.

Even within Microsoft itself, I would guess that investment is focused on the next generation rather than the one that is destined to be short-lived.

One partner that is no doubt close to Microsoft’s plans is Nokia. If the above is correct, then Nokia is buying into the Windows OS, not the Windows Phone OS. Will Nokia wait for Windows Phone 8 before launching devices on the platform? I have no idea – and delay will be costly – but I imagine its main plans will be focused on Windows Phone 8 and the possibility of tablet as well as smartphone devices.

The immediate conclusions would be:

  • Silverlight is safe as a development platform, but only for Windows. See also Silverlight the new Windows runtime, HTML 5 the new Silverlight?
  • The Windows Phone 7 OS will be short-lived but the new UI should be a natural progression from what we have now, and apps should still run, so Microsoft can position Windows Phone 8 to users as a new version of Windows Phone rather than a change of direction.
  • Microsoft will not have a coherent mobile and tablet platform until Windows 8 ships sometime in 2012. Google, Apple, RIM, HP, all have plenty of time to establish their competing platforms.

Appcelerator CEO on Titanium, Aptana and the future of mobile development

I met with Aptana CEO and co-founder Jeff Haynie at the Mobile World Congress in Barcelona last month.

Appcelerator’s main product is Titanium, an SDK which takes HTML and JavaScript source files and compiles them to native apps for several platforms, including Windows Mac and Linux on the desktop, and Google Android or Apple iOS for mobile. RIM Blackberry support is in preview. Appcelerator has recently acquired the Aptana IDE for HTML, JavaScript, CSS, Ruby on Rails, Python and Adobe AIR. The company has also partnered with Engine Yard for cloud-hosted Ruby on Rails applications to deliver web services to clients built with Titanium.

Haynie says that mobile is currently a three-horse race between Apple iOS, Google Android, and RIM Blackberry; but he expects further diversification. Microsoft Windows Phone is under consideration, and he says that cross-compiling to Silverlight would be possible for Titanium:

It’s a .NET SDK, we would have to build a translation into Silverlight. That’s how we do it for iOS, we translate code into Objective C. We don’t think it’s technically insurmountable.

I asked about the Appcelerator Freemium business model. Titanium is open source and you can download and use the SDK commercially for free. Haynie says it works well because companies can do a full evaluation and get to understand the value of the software fully before deciding whether to purchase. However he emphasised that larger companies, other than non-profits, are expected to take out a paid subscription.

This point could do with clarification. Indeed, the Appcelerator Plans and Pricing page shows Titanium Indie which is free but for companies of less then 25 employees, and other editions which are paid-for. But as far as I can tell there are no restrictions on the SDK. See the FAQ which says:

Can I use Titanium for a commercial application?

Yes. You can use Titanium in both a personal and commercial application regardless of what your license or price is.

What is your License?

The Titanium SDK is licensed under the Apache Public License (version 2).

I also took the opportunity to ask about Adobe AIR support in Aptana. It strikes me that this is under threat following the acquisition, since AIR competes with Titanium. Haynie was just a little evasive, but at the same time impressed me with his attitude:

Obviously we have a competitive platform from Adobe AIR. But we want developers to have the best choice, the best tools possible. So competitively we need to build the best product. If AIR is a better product and people want to use Aptana to build AIR apps, then fine. That means we need to continue to work to make a better runtime for the desktop.

Nevertheless, Haynie implied that AIR support will only continue if Adobe supports it; I am not sure what support means in this context but I think it includes a financial contribution:

We’re with Adobe on trying to figure out where we go from here … we have to spend a lot of money to support that, so we’re making sure that we’ve got Adobe’s support behind that.

I am not sure what Adobe gains from Aptana support, given that it has its own Eclipse-based IDE called Flash Builder, so I would not bet on there being significant updates to the current AIR 1.5 plug-in.

Finally, Haynie emphasised what to me are familiar themes in talking about the direction for Titanium and Aptana. Cross-platform visual design tools; designer and developer workflow; and integration in a single IDE of rich client and cloud back-end. This integration has long struck me as one of the best things about Microsoft’s Visual Studio, so it is interesting to see the theme reappear in a cross-platform context.

What I enjoyed about the interview is the way Haynie communicates the huge change and volatility that has arrived within the software development world, thanks to the impact of cloud and mobile. Times of change mean new opportunities and new products. Titanium has plenty of competition, but if Appcelerator is able to deliver a robust, cloud to device, cross-platform toolkit, then it will have a bright future.

I have posted a transcript of most of the interview.

Microsoft backs Telefonica’s BlueVia mobile SDK – but the market is fragmented

Announced at Mobile World Congress last month, BlueVia is Telefonica’s effort to attract developers to its app platform. Telefonica is the largest phone operator in Spain and also owns O2 in the UK, and has various other operations around the world.

In this case though, “Platform” is not just the devices connected to Telefonica networks, but also services exposed to apps via newly published APIs. BlueVia has APIs for sending and receiving SMS messages, delivering mobile ads, and obtaining information about the current user through a User Context API.

Things like sending a text from an app are nothing new, but a difference is that BlueVia will pay the developer a cut from the revenue generated. Along with ads, the idea is that an app can generate a revenue stream, rather than being just a one-off purchase.

The news today is that Microsoft is backing BlueVia with a toolset and marketing to Windows platform developers. There has been an SDK for Microsoft .NET for some time, but today Microsoft and BlueVia have delivered a new SDK for .NET which includes both server and client side support for the BlueVia APIs. On the server, there are templates for Windows Azure and for BlueVia ASP.NET MVC2 and WCF (Windows Communication Foundation) applications. On the client side, there are Silverlight controls such as a DialPad, an Advertising control, and a text to speech control. Microsoft also provides hooks to Windows Live Services in the hope that you will integrate these with your BlueVia applications.

The snag with developing your app with BlueVia APIs is that it will only work for Telefonica customers, thus restricting your market or forcing you to code to different APIs for other operators. “If you want to expose an API in the way that Telefonica is doing, you need to be a Telefonica customer in order to be able to use it,” says Jose Valles, Head of BlueVia at Telefonica.

If you further restrict your app’s market by targeting only Windows Phone, it gets small indeed.

Valles says there is hope for improvement. “We are working with the industry and with WAC in order to standardise this API,” says, assuring me that the reaction is “very positive”. WAC is the Wholesale Applications Community, a cross-industry forum for tackling fragmentation. Do not count on it though; it strikes me as unlikely that a cross-industry group would accept BlueVia’s APIs as-is.

There is also a glimpse of the challenges facing developers trying to exploit this market in the BlueVia forums. This user observes:

During the submission process we could only submit the app for a single device model while it is actually supported on hundreds of models. So please also explain how to specify all the supported models during the submission process

The answer: BlueVia has defined around 20 groups of compatible devices, and you can only upload your app for one at a time. 20 uploads is better than hundreds, but still demonstrates the effort involved in trying to attain any kind of broad reach through this channel.

BlueVia is in beta, but Valles says this will change “in the next few weeks”. That said, it is already up and running and has 600 developers signed up. “It is already commercial, whoever wants to come in just needs to email and we will send it to him,” he says.

The idea of the operator sharing its ongoing revenue with app developers is a good one, but be prepared to work hard to make it a reality.

Silverlight in Microsoft products – Silverlight the new Windows runtime, HTML 5 the new Silverlight?

Is Microsoft ditching Silverlight and embracing HTML 5? Or is Silverlight the future of desktop and browser-based development on Microsoft’s platform?

Good question; and I am not sure that Microsoft itself can answer. There is evidence for both cases.

One thing I have noticed though is that Silverlight is turning up in numerous Microsoft products. This is in contrast to the early years of the original .NET Framework, which Microsoft used rather little in its own stuff, though the context is different today because of the growth in web-based development.

I guess we cannot really count Visual Studio LightSwitch, which is a tool that builds Silverlight applications, though it is interesting insofar as the target market is not expert developers, but smart general users who want to build database applications.

Lync Server 2010 is a better example. Silverlight is used for the control panel.

image

Windows Azure, a strategic product for Microsoft, uses Silverlight for its control panel

image

Windows Intune, for maintaining networks online

image

System Center for managing Microsoft servers. I’m not actually sure how much Silverlight is used in System Center, but I understand the newly announced “Concero”, a new feature for managing public and private clouds, uses a Silverlight control panel and I suspect it is used elsewhere as well.

image

These are a few that I am aware of; I would be interested in other examples.

Now, you can make sense of this to some extent by distinguishing “Windows platform” from “broad reach” applications. It is curious, but Silverlight which started out as a broad reach plugin is gradually moving towards a Windows platform runtime, though it still runs on a Mac with some limitations, mainly lack of COM interop. There has been speculation that Silverlight could merge with the desktop Windows Presentation Foundation and become a commonly used application runtime for desktop Windows as well as web apps, and of course Windows Phone.

When Microsoft wants broad reach, it uses HTML, an example being Office Web Apps which make hardly any use of Silverlight.

Nevertheless, using Silverlight for products like Windows Intune could be annoying for administrators who might otherwise use an Apple iPad when out and about; but I guess Microsoft figures that if you are deep enough into Windows to use Intune, you probably will not be using an iPad.

Let me add that Silverlight seems to me to be working well in the examples above, to the extent that I have tried it. Could they be done equally well in HTML and JavaScript? Probably, if users have IE9, but probably not if it is IE8 or earlier.

Silverlight the new Windows, HTML 5 the new Silverlight?

Adobe AIR 2.6, MonoMac 1.0, cross-platform is not dead yet

It is a busy time for cross-platform toolkits. Adobe has released AIR 2.6, and reading the list of what’s new you would think it was mainly for mobile, since the notes focus on new features for Apple iOS, though AIR is also a runtime for Windows, Linux and desktop Mac. New features for iOS include GPU rendering – a form of hardware accelerated graphics – access to the camera, microphone, and camera roll, and embedded Webkit for apps that use web content. On Google Android, you can now debug on devices connected via USB.

There is also a new feature called “owned native windows” which lets you have a group of windows that remain together in the Z order – this lets you have things like floating toolbars without odd results where toolbars get hidden underneath other applications.

Asynchronous decoding of bitmaps is another new feature, allowing images to be processed in the background. This seems like a stopgap solution to overcome the lack of mullti-threading in AIR, but useful nonetheless.

Since the Flash runtime does not run on iOS, Adobe has a packager that compiles an AIR application into a native app. This is now called the AIR Developer Tool or ADT. You can use the ADT to target Windows, Linux or Android as well; however platforms other than iOS still need the AIR runtime installed.

Adobe is dropping support for the original iPhone and the iPhone 3G. iPhone 3GS or higher is needed.

If you want to build a cross-platform app but prefer .NET to Adobe’s Flash and ActionScript, the Mono folk have what you need. I’d guess that the Mono team has a small fraction of the resources of Adobe; but nevertheless it has delivered MonoTouch for iOS and is working on MonoDroid for Android. Just completed in its 1.0 version is MonoMac, for building Cocoa applications on Apple OSX. Mono is not fully cross-platform, since the GUI framework is different on the various platforms, but you do get to use C# throughout.

I am happy to agree that true native code is usually a better solution for any one platform; but at a time when the number of viable platforms is increasing the attraction of cross-platform has never been greater.

What’s the story with IE9 and embedded Internet Explorer?

There is a certain amount of fuss over the fact that Apple’s latest mobile Safari does not give full performance when either embedded in another application, or pinned to the home screen.

It would help if Apple were more forthcoming on the issue; but in general you cannot assume that embedded browser components will behave the same way as the full browser, even when they share common libraries.

I did some quick experimentation with the released Internet Explorer 9 and the .NET Webbrowser control. First, I tried the SunSpider JavaScript benchmark. I had to use version 0.9 since the latest one gives an error in the Webbrowser control. No great surprise: the embedded version was substantially slower. I ran the tests separately, and for the .NET application I ran in release mode outside Visual Studio. IE9 completed in 314.6ms, the Webbrowser control in 578.2ms.

image

While that may seem a bad result for embedded IE, it could be much worse. Unfortunately I did not think to run this test before installing IE9, so I dual-booted into a Windows install that still has IE8 and ran the exact same application. At 6175ms it was more than ten times slower. It was slightly quicker in standalone IE8, but not by much.

image

Next I tried the Fish Tank demo, which tests hardware graphic acceleration.

image

There were two notable facts about my result here. First, the Webbrowser control reports itself as Internet Explorer 7. Second, the frame rate for the two instances was nearly identical. In practice it varied slightly and some of the time the standalone IE9 was fractionally faster, but still close. By way of reference, Apple’s Safari was around 10 times slower.

Update: embedded IE is slower on the Fish Tank than I first realised. 60fps is a kind of maximum for the demo. Embedded IE9 slows to 45fps with 50 fish, whereas full IE9 does not drop below 60fps until 500 fish on my system. It does makes the fans whir though!

My guess is that Microsoft is more concerned about compatibility than performance, when it comes to embedded IE. However, clearly there is significant benefit from IE9 even when embedded.

How can you get embedded IE not to report itself as IE7 and to use full standards mode by default? If it is like IE8, this can only be done on a per-application basis via setting a registry key. That is awkward for developers, who would prefer an API call to set this. I am not sure if there is any change for IE9.

Microsoft remakes WCF for REST and the web

WCF is Windows Communication Foundation, the part of Microsoft’s .NET framework that handles service-oriented architecture. When WCF was first designed Microsoft was betting on SOAP web services. SOAP is still widely used but since then the trend has been towards more web-friendly services based on REST (Representational State Transfer) and JSON (JavaScript Object Notation). Microsoft has always argued that WCF is flexible enough to support such alternatives.

That said, a project which I have become aware of here at QCon London is the WCF Web APIs, presented here by Microsoft’s Glenn Block. WCF Web APIs focus on support for REST, JQuery clients, and programming model simplicity for a variety of other clients such as Silverlight and Windows Phone. The bit that surprised me is that WCF Web APIs are not just another wrapper for WCF; it is a completely new library that does not build on the old WCF Service Model. The fact that it is called WCF at all is confusing, though of course it belongs in that space within the overall .NET Framework.

I have not had time to look in detail at the WCF Web APIs, but from what I have seen and heard they are well worth exploring, even if you have found the old WCF somewhat impenetrable.

Mono project: no plans for cross-platform WPF

Miguel de Icaza’s report from the Game Developer Conference is upbeat, rightly so in my view as usage of Mono is continuing to build, not only in game development with Unity, a development tool that uses Mono as its scripting engine, but also for mobile development for Apple’s iOS with Monotouch and for Android with Monodroid. These mobile toolkits also give Mono a stronger business model; many sites use Mono for serving ASP.NET applications on Linux, but without paying or contributing back to the project.

Mono is an open source implementation of C# and Microsoft’s .NET Framework.

That said, it is interesting that Mono is still struggling with an issue that has been a problem since its first days: how to implement Microsoft’s GUI (Graphical User Interface) framework on other platforms. Mono does have Gtk# for Windows, Mac and Linux, but this does not meet the goal of letting developers easily port their Visual Studio client projects to Mono. There is also an implementation of Windows.Forms, but de Icaza mentions that “our Windows.Forms is not actively developed.”

Apparently many tools vendors asked the Mono team at GDC when Windows Presentation Foundation (WPF) would be implemented for Mono. WPF is the current presentation framework for Microsoft.NET, though there is some uncertainty about where Microsoft intends to take it. I remember asking de Icaza about this back in 2003, when the WPF framework was first announced (then called Avalon); he said it was too complex and that he did not plan to implement it.

This is still the case:

We have no plans on building WPF. We just do not have the man power to build an implementation in any reasonable time-frame.

That said, Mono has implemented Silverlight, which is based on WPF, and there are some signs that Microsoft might merge WPF and Silverlight. What would the Mono team do then?

Miguel de Icaza says:

Silverlight runs on a sandbox, so you can not really P/Invoke into native libraries, or host DirectX/Win32 content inside of it.
There are other things missing, like menubar integration and things like that.

Of course, this is no longer true on Windows: Platform Invoke is coming in Silverlight 5.

Perhaps the Mono team will knuckle down and implement Silverlight with desktop integration, which would be good for cross-platform Silverlight and compatibility with Microsoft .NET.

Then again, it seems to me that Mono is increasingly divergent from Microsoft .NET, focusing on implementing C# in places that Microsoft does not touch, such as the mobile platforms from Apple and Google.

That is actually a sign of health; and you can understand why the Mono team may be reluctant to shadow Microsoft’s every move with Silverlight and WPF.

DevExpress developers ask for more Windows Forms, say Silverlight and WPF not ready

DevExpress, which creates add-on components and tools for Windows and Delphi, has posted its 2011 roadmap. This shows more convergence between components for Silverlight and WPF:

In essence, by the end of the year, the functionality of DXGrid, DXEditors, DXDocking, and DXRibbon will be the same across both platforms.

As for Windows Forms, or winforms, the roadmap says:

With regard to the Windows Forms controls, it is most likely that there will be a large number of smaller enhancements and new features rather than any large complex new control. The reason for this is simple: we believe that our offerings for this platform are very mature and robust.

Customers posting comments to CTO Julian Bucknall’s blog are not happy:

It is sad to see Winforms pushed back so much. WPF is still too slow on most computers for major apps and SL is not mature enough for a complete ERP app.

says Sigurd Decroos, while Heiko Mueller is more blunt:

Sorry guys, but with this roadmap I will not extend my subscription. I use only WinForms and ASP.NET and I’m not interested in WPF/Silverlight – WPF at this time for me is not suitable for my kind of applications (larger business Apps). Silverlight in my eyes is a dead technology – HTML5 is the future for rich internet applications.

Porting is also an issue says Ioannis Mpourkelis:

I believe that you should put more resources on the WinForms controls for 2011. Winforms is here to stay for many years, especially for the companies who want to support existing Winfroms applications. Currently it is impossible to port WinForms applicaitons to Silverlight and very difficult to port WinForms applications to WPF.

Check the full comments for more.

More evidence for the uncertainty around where Microsoft is going with its rich client API.

Update: Bucknall comments on this specific issue here.

Where is Microsoft going with its Rich Client API? Microsoft drops some clues as developers fret

A discussion taking place in a Windows Presentation Foundation (WPF) newsgroup, in a thread called WPF vNext, shows how Microsoft’s confused rich client development strategy is affecting developers, and offers some clues about what is coming.

Developer Rudi Grobler, who posted on his blog some wishes for Windows Phone, Silverlight and WPF, describes his difficulty in discerning Microsoft’s direction:

The strategy for the future is very vague… I daily get questions about should I use WPF or Silverlight? Is WPF dead? Is Silverlight dead? etc…

Jeremiah Morrill describes his frustration with WPF performance:

Microsoft has known of WPF’s performance problems since the first time they wrote a line of code for it.  You will be hard pressed to find a customer that hasn’t complained about perf issues.  And you will not have gone to a PDC in the last few years and not hear folks bring this up to the WPF team. This is 3rd party info by now, but I’ve been told the issues I have noted have been brought up internally, only to be disregarded.

and remarks his frustration with what has happened to Silverlight:

Silverlight’s strategy USED to be about cross-platform, get-the-runtime-on-every-device-out-there, but it’s obvious that is not the strategy any more.  What happened to Silverlight on set-top-boxes?  Android? I read an article that some people saw it on XBox, but nobody has talked about it since.  Cross-platform with OSX has become symbolic at best.

Developer Peter O’Hanlon describes how the uncertainty has affected his business:

I run a small consultancy, and I bet the company on WPF because I could sell the benefits of faster development time for desktop applications. We have spent a lot of time learning the ins and outs of the platform and saw that Silverlight gave us a good fit for developing web apps. In one speech Microsoft caused me months of work repairing the damage when Muglia seemed to suggest that these technologies are dead and Microsoft are betting the farm on Html 5. We hand our code over to the client once we have finished, and they ask us why they need to invest in a dead technology. I don’t care what you say on this thread, Microsoft gave the impression that html 5 was the way to go.

[…] Muglia’s statement about the future being html caused serious issues for my company. We lost two bids because the managers didn’t want to commit to "dead" technology.

Microsoft’s Jaime Rodrigues, WPF Technical Evangelist, offers the following response:

You are telling us to improve perf in WPF. We hear this loudly and we are trying to figure how to solve it. Unfortunately, there are a few pieces to consider:

1)      First of all,  a lot of our customers are telling us to invest more into Silverlight.  Let’s say (again made up) that demand is  4-to 1. How do we justify a revamp of the graphics architecture in WPF.  This is not trivial work; the expertise in this space is limited, we can’t clone our folks to 5x to meet everyone’s needs.

2)      Let’s assume we did take on the work.  My guess (again, I am not engineering) is that it would take two years to implement and thorougly test a release.  At the stage that WPF is at, a rearchitecture or huge changes on the graphics stack would be 80% about testing and 20% about the dev work.    It is not a trivial amount of work.   Would we get the performance you want across myriad of devices? We don’t know. WPF bet on hardware, and there is new devices out  there that are trading hardware for battery, weight, or simply for cost.  it would suck to do that much work, make you wait a long time, and then not get there. Let’s get real on the asks; you say "improve perf" but you are asking us to do a "significant re-write"; these two asks are different.

3)      By the time we get there, what will be a more powerful framework?  Silverlight, WPF, C++, or SuperNew.Next ??  we don’t know today.  We go back to #1 and look at demand We are in agreement that "customers" is the driving principle.

The WPF has looked at the trade-offs, and risk many times.  We are also looking at what customers need. Jer, to you it is all about graphics.  To many others, it is about data.  So, how do we serve all customers??
The strategy is exactly what you have seen/heard:

1)      WPF 4.5 is going to have some significant data binding performance improvements.

2)      We are not redoing the graphics framework, but we are doing a lot of work to let you interoperate with lower level graphics so that if you need more graphics perf you can get it, and still keep the RAD of the rest of the framework.

[…] Hope it helps; apologies if it does not, and again, wait for Rob Relyea or someone else to make it official.  That is just my 2c as a person who bet heavily on WPF but has seen the data that drives the trade-offs the team has to make.

This will be disappointing to former Microsoft evangelist Scott Barnes, who has initiated a Fix WPF campaign.

The problem though is lack of clarity about the strategy. Look at Rodrigue’s third point above. Nobody can predict the future; but what is Microsoft’s current bet? Silverlight, HTML5, or maybe SuperNew.Next – for example, the rumoured new native code UI for Windows 8 or some variant of it?

My own view is that the current difficulties are rooted in what happened with Longhorn and the fact that the Windows team abandoned WPF back in 2004. I’ve written this up in more detail here.

Lest this post be misinterpreted, let me emphasise that Microsoft has a good track record in terms of supporting its Windows APIs long-term, even the ones that become non-strategic. Applications built with the first version of .NET still run; applications built with Visual Basic 6 mostly still run; applications built for ancient versions of Windows often still run or can be coaxed into running. Build an application with WPF or Silverlight today, and it will continue to work and be supported for many years to come.

My guess is that events like the coming 2011 MVP Summit and Mix 2011 in April will bring some clarity about Microsoft’s mobile, tablet, Windows and cross-platform story for rich clients.

Update: Barnes has his own take on this discussion here.