The early votes are in, and it looks like people want to hear about anything besides my sump pump...

What is the deal with the MSAvalon namespace? To start, this namespace will (obviously) change. Generally we are never allowed to ship any product with any cool codename or team name in the product, so we picked this name intentionally to make it easy to remove later. Most likely MSAvalon will be renamed to "System" - the idea being that the classes that constitute "Avalon" will be in the System.Windows namespace. If you got one of the PDC namespace posters, you will notice that we actually used System.Windows on that poster.

Why did we use a namespace that is easy to replace? Because we ran out of time.

Depending on who you read and talk to, you may have heard some of the story of the Avalon team. I'm not talking about the Avalon umbrella term that we used at the PDC, but rather the group of people that work directly on the team inside of Microsoft called "Avalon". At the PDC we rolled up a bunch of teams under the term "Avalon" as a way of talking about all the great client presentation technology that a lot of teams are working on. A large portion of this work is being done directly on the Avalon team, however we have determined long ago that 99% of the populate really could care less about the organizational structure of Microsoft, so we decided to reuse the name. Fun, right?

Avalon the team was formed almost 3 years ago. It was formed by merging almost 400 people from various teams working on client presentation technologies - some people from Internet Explorer, some people from User32, GDI32, DirectX, WinForms, etc, etc, etc... a lot of people with a wide variety of opinions. As the team gelled and worked on the vision of a unified presentation platform for UI, Documents, and Media they did a lot of experiments and writing of core fundamental code.

About 2 years ago, the Avalon team really started cooking. They had a shared vision and were working hard on producing the large body of code to replace User32, GDI, etc... They began to get some internal customers (a few) and start to actually look at the developer expierence and really think about what people could do with all this great technology.

About a year ago, we really noticed some fundamental problems in the design of some of the components. We made a super hard decision to step back and do a rearchitecture of some major portions of the system. We revisited the tree model that we had, the way controls fit together, our styling system, binding, and more. The end result was a new architecture that was a more holistic view of the entirity of Avalon.

Even with the PDC on the horizon, we made a tough call to begin coding on the rearchitecture, with the goal being feature complete on the new design for the PDC. A lot of people, from a lot of teams, put in a tremendous amount of effort to get this work done in time. However, there were still components that were built on the old architecture of Avalon, and we couldn't break them with only a few months left before PDC. We decided to make the old architecture and new architecture Avalon bits run side by side - and hence we needed a namespace for the new bits. MSAvalon was born.

Once we get the last of the internal customers that depend on the old architecture bits moved over to the new architecture, we will retire the old namespace and eventually remove the DLLs from the build. After that, we can do the monster namespace change to move to the new namepsace.

It was really interesting some of the discussions that we had around this change. There were really two camps inside of the team - one said that we should ship the old architecture bits as they were more mature and had more features. The other camp said that we should push as hard as we can to give the developers at the PDC a preview of the design that we were moving forward with. There wasn't a perfect answer - the old design would show more of the intent of what we wanted to accomplish, but the new design would show more of our developer API.

In the end we decided to push forward with the new design - getting feedback from developers about our new model was determined to be the top priority. We need to hear if the explicit styling mechanism, element composition, data binding, logical tree split, etc, are usable and in the right direction.

There was amazing effort put forth by so many people to make this happen it was mind boggling. Taking a team of 400 people, and an even larger group of internal customers and partners, and making a radical design change 8 months before a public release was an amazing risk... I really hope you all feel that it was the right decision...