Vince has responded to my "Defending the Rich Client" post.
He works on writing games for Midway and has a unique perspective. He says that the type of games that he writes are the ultimate rich client. To a certain degree I agree, but I'd like to dodge some of that as this is a market where Avalon definately isn't targeted.
However, Vince does talk about internal authoring tools for games such as level editors and he has some concerns with how plausible it would be for someone to start taking advantage of the CLR and Avalon. I'm not an interop expert, but here are some thoughts:
- Add-ins for other packages. If those packages are DLL based, you can always use MC++ to write add-ins. With both WinForms (I think) and Avalon, you should be able to write UI that can be hosted via hwnds. If the package is COM based, you can either use MC++ or CLR COM interop support.
- Writing a new tool. You shouldn't have to start from scratch. You can host windows that are written in unmanaged code in both WinForms and Avalon. Beyond this, you can manage internal intefaces via P/Invoke, COM interop or MC++ (if you aren't happy with the current managed C++ implementation, all I can say is that the team has heard you and changes are in the works).
The next question: Is it worth it? We definately hope so, but there is nothing stopping you from continuing to use the technologies that you are currently using. Managed code and garbage collection aren't the solution to every problem. There are certainly places where it does make sense to drop down in to unmanaged code, just like there are places where it make sense to drop down in to assembly.
So, if you do decide to jump, will it do everything that you want? Vince gives an example where he can't get a specific behavior out of WinForms without dropping down and P/Invoking. I'm not sure what is going on here, but the reality is that there are going to be things that we don't wrap or don't think of. That is just the challenge of writing a platform -- we try to expose as much functionality as possible in as easy to program a way as possible while leaving as much room for extensibility as possible. This is a complicated equation and we are sure to miss stuff. To complicate things, when we move forward with something that is more than just evolutionary (WinForms and Avalon, for example) there are going to be regressions in functionality. We may have decided to change the equation from one framework to another. All I can really say is that we try our best and please let us know if there is something we missed.
Next, Vince looks at my 3 reasons to write rich client apps: presentation, local storage and network connectivity. How important these are to different developers and users depends on specific circumstances. While local storage may not be that big a deal for networking, it would be huge for an online image gallery application with a smart client interface (it looks like the guys at nGallery are eventually headed in this direction).
One area where the web model has been ahead of the traditional Windows APIs is the ease of connecting to the network. But it was the case where there were things you could do with Win32 (raw network access) that you can't do with a typical browser and there are things that you can do with the browser (talk http to load and display an image asynchronously) that are super hard in Win32. Making the smart client better is all about removing these "either-or" choices and giving you the best of both worlds.
Lastly, Steve rails on the fact that it looks like MSBuild isn't going to support VC++ out of the box. I have no clue what is going on here but stay tuned to AKipman's blog for news.
Overall, I really think that this is a healty debate and I thank Joel for getting it started. Hopefully this gives everyone a little insight in to why we are doing what we are doing in Avalon and Longhorn.