Ah, Ryan
doesn't like our decision to redist Avalon downlevel (probably the first person
I've heard of who doesn't like it)...
He makes four points, from what I can see:
-
Xamlon provides Avalon's value on XP
-
The WinFX redist will be 100MB-200MB
-
Avalon on XP is going to have massive technical problems
-
Avalon on XP means big Avalon feature cuts
Let's tackle these one at a time...
Avalon and Xamlon
Xamlon, from what I can tell, seems to be a XML
to C#/VB/etc compiler. It is mostly a clone of the XAML syntax, and supports binding
to WinForms classes. My appologies if I don't understand it enough. An XML dialect
for describing UI is only one aspect of Avalon. Avalon represents an entirely new
display system, from a new font engine (including support for new OpenType features),
animation engine (with hardware acceleration), control library (with composition),
application model (including rich browser integration), and more.
Avalon's tenets are "Best of the Web, Best of Win32", while the declarative definition
of UI is definetely one of the "Best of the Web" parts, it's ridiculous to boil down
3 years of work from 300+ people to this one feature.
WinFX redist size
I'm amazed that Ryan knows the size of our redist - I don't yet. We are still working
out the plans here, but at the moment I can't comment on how big I think the redist
will be. Having fear over the "possible" redist size seems like a bad way to make
decisions.
Avalon on XP technical problems
I'm still fairly suprised at Ryan's "knowledge" of our internal state, he says "Obviously,
the technical problems are going to be far and wide". Yes, there are going to
be technical challenges to overcome (robust hardware acceleration on the XP driver
model, for example) but claiming that these are "far and wide" is again, quite a bit
premature. I've worked with most of the teams on Avalon and we are identifying any
potential issues with running on XP. We've identified some, but overall we are solid.
Joe Beda has a great post about some of the limitations...
Avalon feature cuts
I'm not sure why Ryan thinks that going to XP means feature cuts. When shipping a
product the number of platforms you support is mostly a testing issue, it means a
large matrix for running your tests against. Yes, there is a lot more surface area
for developers to manage, but the presence or absence of a platform doesn't relate
1:1 with features. From our product planning standpoint, the reality of a hard date
for Longhorn is more important. Now that we have a solid date, we can get much more
realistic about features. I'm not saying that we aren't going to change the feature
set (somewhat), but rather that the primary motivation, generally, is the date rather
than the platform list.
As for Ryan's claim that "I can’t speak for anyone else, and I doubt you will
see any criticism from within Microsoft because it is a career limiting move, but
I will say that I am very disappointed."... give me a break. When I disagree
with MS policy/decisions I'll say it. In this case I believe this is exactly the right
thing to do for developers, consumers, and Microsoft.