Jon Udell's blogs turn into a cover story
Jon Udell has turned his series of blog entries on Longhorn into an InfoWorld cover story . His editor makes the point that the blogging drove some great discussion and contributions to the final article. It’s cool to see that discussions I took part in with Jon, like here and here, had an impact on the final article. I’m also glad that after talking to Quentin Clark, Jon concluded that “If you're investing today in XML document formats, you should expect WinFS to do a good job running XPath or XQuery searches over them”. There’s a lot more from Quentin on Jon’s blog.
I think the final article came out well. I particularly like the order in which Jon lays out the WinFX pillars, since this is exactly how I do it when I give a WinFX overview:
- First you need to get your data, no matter what device, server or service it lives on. You want to get to it in a secure, reliable way. That’s Indigo
- Now you need a way to store it locally, so that you can find the relationships between data from all these disparate sources and turn it into useful information. That’s WinFS.
- Finally, you want a way to see that information, a compelling visualization that makes sense of it all. That’s Avalon.
Jon also made the point about WinFX betting heavily on .NET as a foundation: “One thing that's not in question, however, is Longhorn's deep commitment to .Net. […] That's great news for the long-term health of Windows, the productivity of its developers, and the security of its users.” I’d agree. When ISVs ask what they can do to get ready for Longhorn, the first step is to get familiar with .NET and managed code. If you have an existing Win32 app, look into the enhanced C++/CLI support in Visual Studio 2005. If you’re starting on a new app, write it in managed code from the start.
Only one sentence in the article struck me as not quite right: “Microsoft is doing nothing to improve Internet Explorer's support for DOM, CSS, SVG, or other standard ways to enrich the browser.” It might be accurate to say that the Avalon team aren’t investing here, but read the comments of IE’s Group Program Manager, Tony Chor, over at Channel9, or read IE Program Manager Dave Massy’s blog, or take a look at the community discussion on the IE wiki. I’m pretty sure these guys are doing more than nothing to enrich the browser.
Thanks to Scoble for pointing out that the article had hit the web.
Comments
- Anonymous
July 20, 2004
Jeremy, while you are correct in asserting that the IE is working on security for IE and making a few enhancements for XPSP2/6.05 - it is also the unfortunate truth the IE has seen nothing but security patches since the summer of 2001.
When you consider the bad press that IE has gotten due to security, the lack of substantive updates (client UI and rendering features) and the possiblity that the next IE will only be a part of Longhorn - these combine to create a major source frustration between users and developers.
MS has done a great job on improving its comunication through blogging and opening open the .Net/platform development process. However, except for the few comments from Tony - which were by the way very welome - the future IE remains a contentious issues due to the lack of a clear vision for the product, and a development team that seems to be shrouded in secrecy.
I understand that the next IE will be Longhorn ready and that it the Longhorn platform - though approaching stability - is not yet complete so it's hard to pin down a new direction. However, that's no excuse for disengaging the general public and especially developers. The Channel 9 discussion is a step in the right direction. Hopefully, we'll start to see more comunication from the reconsituted team as the Longhorn beta approaches. - Anonymous
July 20, 2004
Hi Lynn,
You are quite correct. We have gone too long without updates. As Jeremy pointed out we are very aware of the issues and are looking hard at what we need to do to move Internet Explorer forward. We've seen plenty of good feedback on this on both my blog and the Channel 9 Wiki. The first priority for the team has quite correctly been on security and we can see the results of that work in Windows XP SP2.
We certainly don't mean to come across as "a development team that seems to be shrouded in secrecy". We expect to be more communicative about what we are doing as we move forward. At the moment though we are still early in our planning so I'd rather say nothing than set expectations incorrectly. I can assure everyone we really appreciate everyone taking their time to give us feedback.
Thanks
-Dave Massy
Internet Explorer - Anonymous
July 20, 2004
Until Visual Studio 2005 ships, it's difficult to fully embrace .NET for anything except a 100% new application.
I started work on a new application last fall (Sep'03), but it had to be implemented as a plug-in (DLL) to another application. Because of legacy interactions with MFC, I had little choice but to code it all in traditional C++ rather than C#.
So .NET is a very nice story, and I fully agree with it; but in the real world we can't get there yet. - Anonymous
July 21, 2004
Did you try the Managed C++ functionality in previous VS versions? It's not as nice as the new C++/CLI work in VS2005, but it should provide at least some mechanism to write managed code that interops with legacy C++ code. There are a series of older samples and articles at http://www.gotdotnet.com/team/cplusplus/. - Anonymous
July 21, 2004
VS2002 does not officially support hosting a .NET control in a MFC dialog (I know this can be done in VS2003); we were stuck with 2002 because we can't break binary compatibility with every release.
I've tried the /CLR flag at times (and am still working on it), but it's not quite as straight-forward as the Quake whitepaper makes it sound. (See http://sourceforge.net/tracker/index.php?func=detail&aid=973424&group_id=7586&atid=207586 for example).
Don't get me wrong, I think .NET is great and I'm trying to get there ASAP. But at times, it seems that the evangelists at MS are a little too disconnected from life out in the trenches. At least I can be happy that we're not still using VC6...
And now it's starting to look like we're going to have to do a third release on 2002 because of 2005 slipping. :-( That means more non-.NET code being written in 2004...