Yesterday I received my order for Vista Ultimate and Office Ultimate. I'm already running Vista RTM bits on my main machine at home (I had a Beta and RC version, so I upgraded to RTM bits as soon as they were available internally. I believe this is the correct thing to do based on corporate policy... if not, someone should let me know. I did buy a full copy for every machine in my house once it was available).

This morning I kicked off the installation of Office, or rather the upgrade. Some comments:

• the new packagine is clever, not too intrusive but distinctive. I think I like it.
• Product keys suck. Having to type of 25 digit string of characters to install software is frustrating for me. Not too big of a deal on my PC - the one I really really really hate is doing this on the XBox.
• The installation is running, and so far I have only had 1 UAC dialog prompt.

I really enjoy using Office 2007 at work, so I'm pretty happy to finally have it up and running at home.

 

Oh, wait... not really. $499 for a fully equiped desktop running Vista (OK, you need to add a monitor)... $699 for a laptop. I know this isn't quite as good as Sells' $365 Vista machine, but it's a good start.

It's great to see Vista release. I spent a lot of time working on WPF, which I believe is one of the core parts of the new Vista experience. The Avalon team, depending on how much of the organization you include, peaked at around 250 people, with another 250 people working in the "Windows Client Platform and Documents" team that Avalon was part of. It was a massive effort. The overall team built features ranging from the XPS document format, the desktop window manager, WPF, and the Windows Imaging Components (WIC) - to name just a few.

I'm proud of what this team accomplished, and I'm extremely proud to have been part of that team.

Congratulations to everyone who contributed to this release. I know we would have all liked to see it get out the door before now, but we have a lot to be proud of.

... now, let's get back to work and make it even better!

Greg Schechter blogs again... now all DWM, all the time... well, kinda.

Thanks for the response Miguel... I'm still trying to digest the Slashdot thread also (I'll respond on Slashdot for that thread... )...

Before I start, I'm not taking any of this personally - I really enjoy debate, regardless of the opinions. As far as I'm concerned, bring it on! More Feedback == Better.

Security

The low-tech (aka phishing, aka con artist) attacks are being worked on. The social engineering and human behavior/interaction research is happening, it's just not on my team.

As for the "weakest link" characterization of ClickOnce, I think you are confusing some things.

ClickOnce is a deployment technology that improves upon the base technology introduced in .NET 1.0 for downloading and loading code. ClickOnce supports a subscription and application manifest. A principle advantage to the approach is that a customer can establish a subscription to an application and get automatic updates. In addition, the application manifest creates a complete descriptions of the parts of the application - enabling both validation and download/install/uninstall to be implemented by the system.

Next in the stack is CAS - Code Access Security. This is the security system built into the CLR. This technology has been in place since .NET 1.0, and we are continuing to iterate on it. In addition in Whidbey (the version of the CLR that we are talking about here) has a new level of application level security that can "lock back" the permissions of the loaded assemblies to that of the application, further limiting attack vectors.

In the middle of this is the TrustManager. This is a piece of code that provides a user with a single consistent prompt to determine what they want an application to be allowed to do. For example the application might request higher permissions or local installation. The goal here is to remove the half dozen security dialogs that users get prompted with today, and messy installation wizards, with a consistent user experience, giving them complete information.

All of this technology together, gives us the user experience that is (as you put it) one of the fundamental reasons for Avalon to exist. A perfect (or much more secure) computer would be one that you never plug into any network and have no software installed. You wristwatch is pretty secure is my guess.

We are doing usability studies on all of this, to validate that this is going to improve the situation... I'll keep you posted.

Complexity

I've used a handfull of GUI libraries; VB6, IE, WFC, AWT, Swing (limited exposure), KDE/QT (very limited exposure), and Cocco (limited exposure). Cocco was amazingly complex in my usage, the library felt like MVC on steroids with a pretty cool UI designer. KDE/QT felt a lot like WFC in C++, fairly straight forward. Swing, was, well, swing. MVC everywhere, powerfull, but very complex. I found that at JavaOne most of the Swing sessions started with a 15 minute talk on how you really can make Swing fast if you just understand MVC more. I think that the recent versions of Swing are much improved on this, my data is a little dated here. AWT was simple, but I felt that the event adapter model and peer model didn't lend itself to good usability, toolability, or performance. Anyway, I could go on... I'll try to take a look at Tk and XView, if they offer better simplicity, it would be great to learn from them.

The point about abstracting implementation from API is very interesting. The COM model has a very clear abstract, but removes the ability to deal with implementation inheritance. The AWT model of peers supported inheritance, but the real meat of what you wanted to deal with was locked away in the peer. We really wanted to embrace the "component framework" model that is present in ASP.NET and Windows Forms (yes, I know they have a peer model because of the HWND, but the WndProc is directly accessible, etc.)... the idea was to provide component developers full access to the implementation and not special case any Microsoft code as much as possible. The idea being, anyone should be able to implement "Button" and do all the same features we did, with no penalties.

This does come at the cost of more public exposure, but we hoped it would be worth it.

I know that Button is too trivial of an example to really talk about, so lets talk about lists, or more specifically ListBox. In most programming models that I've used the ListBox has a data model of providing strings - this is the Win32/AWT way (I think Cocco also?). Windows Forms added support for "object", but basically you had to .ToString() the thing to get it to display... unless you implement your own custom rendering. In all the systems I've seen the custom rendering is implemented in a completely different programming model - paint code in most systems.

Avalon has a simple "scalable" model. When I say scalable I mean to imply that the API starts simple but can scale up to support complex scenarios without requiring a massive leap in understanding - pay for play in complexity.

<ListBox>
    <string>Hello</string>
    <Image Source="http://..." />
    <Button>Hello</Button>
</ListBox>

You then can get into styles to manipulate all of this:

<Style>
    <ListItem />
    <Style.VisualTree>
        ....
        <Rectangle RadiusX="5" RadiusY="5" />
        ...
    </Style.VisualTree>
</Style>

The key thing is that I never had to switch programming models. Yes, if you try to digest everything at once (styling, binding, commanding, visual trees, etc.) then the system is complex - but the goal was scalability - Make simple things simple, and hard things possible.

Standards

First, an old post from Joe Beda about SVG and XAML.

Second, dismissing the CSS debate isn't really fair. A critical part of our design is unification. We didn't want one markup model for vector graphics, one for styling, one for 3D, one for data, etc. Another part of the unification was "Markup == OM", that is, we didn't want a separate markup programming model from code. HTML is this way, the markup and the code have a loose relationship. If we ignore the unification debate, I can understand how it seems simple to say "you should have used SVG".

Avalon is a developer platform. We want to enable an entirely new breed of applications that span UI, graphics, and media. Integration of typography with imaging with video with controls with styling is a core part of our value proposition. We aren't trying to create a new 3D system or animation system, we are creating a new developer platform.

First, before anyone but Miguel reads this post, please read Miguel's comment on Longhorn changes.

I'll wait.

No, go read it first, this post will still be here after you are done.

Ok, now that we all have the same context, let's continue.

Security

I totally agree, this is a huge issue. Phishing attacks, spyware, malware, viruses, and more are out there and probably the largest problem facing computer science today. This isn't a Microsoft, Linux, or Java issue - this is a "good guys" issue. Windows XP SP2 is probably the best response to Miguel's security concerns. The integrated firewall, security center, and dozens of other security related features are really the first line of defense.

After the basics are resolved there, I would say that the new enhancements to the security system in Avalon are a great step. Not only is Avalon built from the ground up to be secure, but we are enhancing the security system for better application level security, and simpler more understandable presentation of security decisions to the user (hopefully in most cases this means no decision).

As to the specific issue of Phishng that Miguel brings up, that is still mostly a research level issue, which I'd love to see creative solutions to. In Windows today there is the secure desktop, but you must press Ctrl+Alt+Delete to get to it first.

Complexity

Ouch, I take this one to heart. As an architect on Avalon I find it to be my failing when someone says that it is too complex. To be honest, the specific issue that Miguel raises around the object hierarchy is something that I hoped most people wouldn't find to be a huge issue. I figured that most people would look at the features available on the class they were using (like Button), instead of digging into the object browser. The factoring (or over factoring) is our attempt to have a clean model.

From experience, I can think about WinForms. There we had a significantly large simple base class - Control. It implemented almost all the functionality common to the framework, but as such, it implemented properties that some controls outright ignored. Some folks claimed this made WinForms too complex because you couldn't know which properties would affect which controls.

I'm not claiming that Avalon has it right, the object model depth is something we continue to debate, but I will say that we did made a conscious descion to balance OM cleanliness with OM hierarchy.

As for the "fully cooked" argument... come on Miguel. You are looking at something that isn't even a beta product.

Ignoring Standards

Interestingly enough, we never "ignored" standards. We spent a huge amount of time understanding and evaluating the existing standards. SVG and CSS both were passed on because they weren't adaquate to meet our needs. WinFX is a platform for the next decade or longer - we can't start with a base that doesn't meet our needs.

Wesner posted about this a while ago... I posted about it also...

Canvas model

I'm pretty sure that Miguel is talking about "retained mode graphics" here, not our Canvas layout panel...

Avalon is actually more of a smart caching model for graphics. In fact we can run in fully immediate mode, where the visual provides the drawing instructions when needed. The big delta with Avalon is that the display is always buffered, primarily for compositing reasons (we use compositing instead of clipping like User32).

Lack of a GUI designer

This is spot on - I completely agree. Luckily this isn't the first that we've heard this issue, and I'm hoping that we have a great story when we release.

Final Thoughts

Miguel closes with some comments about the "death march" that may happen: "I realized that the Avalon folks now must do two products instead of one: they need to build an Avalon for Longhorn, and another Avalon that will run on XP. It seems that they just added a pile of work to a team that was not ready to release their software."

I'm not sure where Miguel got the idea that we would have a different source base for Longhorn and XP. The "pile of work" is there - shipping for multiple platforms is a lot harder than one - but this isn't an order of magnitude difference.

Miguel, thank you for a very well thought out post, with a lot of good feedback. I disagree with a lot of your points, but you have a lot of valid concerns. I'm particularly concerned/interested in more issues around complexity. As the title of my blog indicates, I believe strongly in simplicity. Every day I try to make Avalon simpler - in fact I really do have a review goal to make the beta of Avalon simpler than the PDC build.

For everyone else out there - keep the feedback coming. We are listening!

[updated: fixed a spelling error]

In all the conversations about what is possible on XP and isn't, one thing I've neglected to mention is the idea of WinFX on Longhorn.

Let's take something like Avalon, which will have some limitations on Windows XP. While we are still working out the details, there is a possibility that reliable hardware acceleration may not be possible on Windows XP due to the display driver model. For now, lets imagine that we can't hardware accelerate on XP. Longhorn will still contain the new Longhorn Display Driver Model. This means that WinFX applications running on Longhorn will run with hardware acceleration, even if it isn't possible on Windows XP.

When people worry over limitations that may be imposed on WinFX downlevel, it's important to note that those limitations may be significantly different (or removed altogether) on Longhorn.

Wait! Before you panic about application compatibility. The example above talks about Avalon, today there are already circumstances where software fallback or hardware acceleration will be used - we already ensure that these two modes will be completely compatible.

In the comments on Ryan's post, he asks:

"My next question, though... with all the talk, can you guys back up your decision to do the downlevel support."

Great question. Unfortunately I really can't answer, I mean realistically the decision was made far above my pay grade. I can talk about why I think we made the decision, but in the end this was a decision made by Jim Allchin, Steve Balmer, and Bill Gates. Seriously, they were involved in the final decision making process.

I believe that we made this decision primarily based on customer feedback. At the PDC and WinHEC we got consistent feedback from developers that they wanted Avalon downlevel. Of course, they also said they wanted Avalon to run on all platforms (including Altair), but we knew that they really just wanted Windows XP <G>! Seriously, feedback from developers was consistent - they wanted the developer platform to be available (in some form) on a broader range of operating systems.

As a stockholder, I have to ask the question - Why would you give away the developer platform?! As a stockholder I want MSFT to monetize every technology they can to increase revenue and drive shareholder value. Ah, but nothing is ever that simple.

Let me introduce a pet theory of mine - Developer value vs. Consumer value. Developer value drives developers to adopt some given platform for building their applications. These applications drive adoption by consumers for the value of the application - not the platform. Consumer value (of the platform) is driven by end user facing features. There are also IT administrator value, and tons of other value propositions, but for now lets talk about Dev and consumer.

Developers want the platforms they target to be available to the broadest set of consumers. Consumers want the platforms they use to run the boardest range of applications. Consumers also want the platforms they use to offer the richest experiences.

To me, having WinFX broadily available is all goodness for developers (whom I love). Having Longhorn focus on delivering amazing experiences is goodness for consumers (whom I also love).

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:

1. Xamlon provides Avalon's value on XP
2. The WinFX redist will be 100MB-200MB
3. Avalon on XP is going to have massive technical problems
4. 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.

I'd happily help Benjamin out on his OSCOM 4 challenge... Just drop me a line!

Soma (you know, the VP that runs the developer tools division at Microsoft) sez "keep writing managed code on the .NET Framework today", and I can't agree more!

Joe expands on my simplistic answer to the "can Avalon run on XP" question:

"

1. Lack of the LDDM (Longhorn Device Driver Model). Right now the XPDM (XP Driver Model), wrt DX, is really built to work well for one app at a time.  It uses first come, first server, winner take all approach to resource allocation.  While Avalon runs just fine on the XPDM, it isn't clear that lots of Avalon apps running at the same time will work really well without the LDDM.  There are also concerns around the stability of current DX drivers under the XPDM.  These drivers have been written with the gaming market in mind.  Using them for every day applications may push them to some breaking points.  All sorts of options are being considered on how to deal with this.  And for machines that we can't support hardware acceleration on, we always have our software rendering layer that we can fall back to.  Early on we decided no to rely on hardware being available on every machine.  That decision is paying off now.
2. Inability to really tweak User32. In Longhorn builds we had the ability to do "child window redirection".  This is a Win32 interop solution where child hWnds get redirected by the system to a bitmap that the Avalon compositor then hosts.  This allowed Win32 content to alpha blend and rotate just like any Avalon content.  Since we won't be able to change system binaries on older systems, we won't be able to do this redirection on XP and W2k3.  We'll have to find a compromise solution to hosting legacy content.  You probably won't be able to treat it like regular Avalon content.  Eventually we want to be able to support these advanced legacy hosting solutions, but it probably won't work on XP and W2k3.
3. Terminal Services and Remote Desktop. We were planning on remoting Avalon at a completely different layer.  It is unclear how we will address this issue on platforms other than Longhorn.  The long term plan and architecture still encompass enhanced remoting.
4. Media decoding system.  A lot of the video hosting relied on components being delivered from the media team.  Since we are now perhaps shipping via a different mechanism than they are, the level of integration and interdependencies are now up in the air.  We are working on figure that out.
5. Desktop Window Manager.  The DWM will still exist and be included as part of Longhorn.  There are no plans to make the DWM run on XP and W2k3.  The cross process UCE architecture presented at WinHEC remains unchanged for when Avalon apps are running under the DWM on Longhorn.

" [EightyPercent.net]

John Montgomery talks a bit about the behind the scenes of the recent announcement... I have to say that I completely agree with him. That Microsoft is still willing to a) try massive undertakings and b) willing to make major course corrections, is an indication to me that the company is still vibrant and strong. The great thing (to me) is that senior management has now cleared the runway for us development teams to execute...

While I thought that WinFX and Longhorn where much more than that, I really like Peter Torr's Hello World post to illustrate the trials and tribulation of shipping.

"In the end, Microsoft got what it wanted, but not in the way it wanted. They said that Longhorn was going to be a revolutionary operating system, and I believe that it will be. The architectural side will definitely improve, but the revolution will take place where it really belongs, in ensuring that computers are as easy to use, easy to manage, and resiliant to attack as possible. And that can only be good for everybody." [Robert McLaws]

Jeremy chimes in on the announcements...

Well, the news is out now, and everyone is starting to talk about it.

Personally, I am totally excited about this. For the past couple weeks we’ve been working out what this means for Avalon, and so far it is shaping up to look pretty good.

<highLevelStuff>
Longhorn in 2006, with a firm commitment from management, is a great thing. Getting more components of WinFX running on more platforms is a great thing. Indigo was already on this plan, and I’m happy to have Avalon on that plan also. We listened to developers, and they all resoundingly told us that more of WinFX needed to be downlevel, so we are doing it. WinFS was a big bet, and still is, the fact that it will be a bit later doesn’t lessen the importance or commitment to it.
</highLevelStuff>

But what does this really mean to Avalon?

Since that is the team I work on, it’s really the only thing that I feel informed enough about to talk about… Let me try to answer what I think will be the most common questions (for the official FAQ, check out WinFX on down-level):

1. How can Avalon run on XP, I thought you said it required Longhorn?
Probably the deepest dependency Avalon has on Longhorn is in the new display driver technology. The DX stack is largely designed for a single application to have absolute control over the video card at a time (think full screen gaming). To really do multiple 3D applications running simultaneously with a composited desktop, we needed to make the GPU a shared resource. In the new Longhorn Display Driver Model (LDDM) we were introducing technology for resource virtualization and scheduling support on the GPU. Without this, we have some tough problems to solve, not intractable problems, but tough. Realistically though, there will be some limitations to what we can do on XP – I just don’t have that complete list today.

2. What does this mean for developers?
Obviously the availability of Avalon for Windows XP and Windows Server 2003, in addition to Longhorn, will make it viable for a lot more developers to begin developing applications using Avalon. This is really a large part of our reason for wanting to move downlevel.

3. Is this why you haven’t been blogging for a while?
Partially, planning for this has been occupying a lot of my time… hopefully I can get back to blogging more regularly!

4. Does this announcement change your sump pump plans?
No. Unfortunately my sump pump doesn’t run Windows XP today, so this will not change my plans.

5. Will <insert your favorite feature /> be in the Windows XP version of Avalon?
I can’t say at this point. As with any product as we push towards the release date the feature set will change (new features from customer requests, features cut for one reason or another).

6. What does this mean for WinForms development?
I love WinForms. I worked on WinForms for years, and I still believe it is the best way to build smart client applications today. WinForms will continue to be the way to build smart client applications for the next several years, even after WinFX is released. WinForms is available on more platforms (Win9X, Win2K, etc.) and has a more mature control set and tools story. We are working hard on a great story for migration and interop between WinForms and Avalon.

7. I read in <insert news site /> that Avalon is cut, is that true?
No. We are absolutely committed to delivering Avalon, and from everything I’ve been told, heard, and am planning - we will ship it!

8. Will Avalon have a visual designer?
We are working on our tools plan, but I don’t have anything to announce today.

9. Does this change how your team is working?
Our team is generally excited by this plan, with change there is always some trepidation, but almost everyone is jazzed about being about to deliver more value to more customers. The team is probably going to shift their primary development platform to Windows XP for the next several months, but we will still have Longhorn as a primary test platform. This new plan gives us a lot of clarity about what we are delivering. Otherwise, not much else changes - our core mission of "best of the web, best of Windows" remains unchanged and our philosophy of unifying documents, ui, and media remains unchanged.

I can’t wait to get this stuff into developer’s hands. The fact that I can now ship this stuff to a large set of customers makes me super excited. This is exactly what developers have been asking us for, and now we are able to give it to them!

 

Daniel has started up his series of intro to Avalon 3D... which he called 3D for the Rest of Us. Of course, the first thing I want is the source to all his samples!

I have a confession to make... I'm not a 3D expert. I know the basics of 3D using Maya. I've dabbled with just enough math to know the names of some of the things I need to do 3D. But, I have another confession - I lust after 3D. I've always wanted to be the guy who could build cool 3D worlds. But alas, I haven't ever taken the time to get down and dirty with Direct3D. Now, of course, I have a job requirement to understand 3D.

Because of my lack of deep understanding, I went straight to the source and cornered Daniel in the hallways and asked what material I should start studying. He offer to give me a short tutorial on how to build 3D using Avalon, on the condition that he could post it to his blog. I had to accept.

Anyway, the first tutorial isn't posted yet, but keep an eye on Daniel's Blog...

Daniel Lehenbauer joins the fray... Daniel is a dev working on the Avalon 3D support...

I have good news and bad news...

The good news is that I found out today the real specs for the IBM T221, one of the super high density displays (204dpi)... IBM's display is 22.2 inches with a max resolution of 3840x2400... this thing is truely spectacular in person (there is one floating around the hallways in my building)... It can accept anywhere from 1 to 4 DVI inputs... very cool...

The bad news is that I also found out that I misquoted just about every one of the specs in my blinking lights article... Hopefully it will be relatively trivial to get MSDN to post an update...

Sorry for any confusion, and if anyone finds any other glaring technical issues please let me know!

So IanG and Jason Olson have run across the glorious Avalon UIContext.

There is some debate internally about if we should allow UIContext.Enter() at all. The problem is that your context may get pinned to a specific thread (for example, if you host an HWND or use COM). Once you have a pinned context you need to marshal the call to the right thread, you can't just call enter.

The question is then: Should we have an API that works depending on the state of the context but provides occasionally the simple pattern (UIContext.Enter()) or should we have one API that is always guaranteed to work but is harder to use (UIContext.Invoke/BeginInvoke)? 

Marc Clifton seems a bit frustrated that XAML isn't the end all be all serialization engine. XAML is a general purpose markup format, but in Longhorn there will be a new general purpose serialization engine.

XAML was designed to be a compromise markup format, that balanced the toolability and readability aspects of a markup. You can think of HTML as a markup that was squarely designed to be readable, but not very toolable. SOAP on the other hand is very toolable, but almost impossible to read. In the design of XAML we constantly walk the line between the two. XAML has support for inline code, customer parser extensions, and multiple representations of the same structure.

In Longhorn there will be a new serialization engine in WinFX. The goal of this new engine is to unify the scenarios addressed by the XmlSerializer, SoapFormatter, and BinaryFormatter.  This engine (residing in the existing System.Runtime.Serialization namespace) will allow serialization and deserialization of any CLR object graph (graph is a carefully chosen word here) to a variety of different formats (including XML and your own custom ones, if you wish).

Lets compare the two methods:

XAML

• Objects must conform to a specific contract (public properties, empty public constructor)
• Extensions done through interfaces on objects (in other words you must load CLR types to serialize or deserialize the format)
• Only supports object trees (no graph support)

System.Runtime.Serialization

• Any object regardless of shape can be serialized (properties, fields, events, private or public data)
  Extensions done through declarative metadata (DataContract attribute), which means you only need metadata or schema to parse
• Graph or tree structure

XAML is designed to be more of a mix between a document and a programming language (something like ASP.NET's markup) with a fixed grammar where as System.Serialization is designed to consume and produce arbitrary XML and CLR graphs.

My last meeting was down near the conference center so I'm hanging out in the back of the room for Steve Lasker's presentation. There are a lot of MVPs here. I hope that Don & I will be entertaining for the group... I think this group of folks have been in presentations all day, which makes for some tired MVPs... maybe we should serve beer in our presentation?

Not sure I really agree with Scoble here. I talk with the WinForms and Avalon folks a lot on a regular basis, and I think trying to pick a date in the future like "2012" or "2014" is a Bad Thing.

I spent many years working on WinForms and I love that technology dearly. I know almost all of the current development team on WinForms. I talk with them all the time, and I try to have a good grasp on their plans for the future.

I have been working on or with Avalon for a couple years now. I think I have a relatively good handle on what we are producing and how this maps to the WinForms technology.

The idea that people should adopt WinForms because Avalon is 8 years out is just ridiculous. People should adopt WinForms because it is a great development platform for creating smart client applications. People should adopt WinForms because it puts them in a great position for transitioning to Avalon when they choose to.

I think that customers should move to managed code because of all the things that Scoble mentions - it is our future platform, where we are investing in going forward, and the best platform for writing applications (productivity, power, etc.).

Developers know when they are ready to adopt new technologies based upon *their* customer's feedback. For some developers they will have customers that want Longhorn exploitive apps on day 1. For other developers they will have to wait. There are still people writing code (lots of it!) for mainframes, Win98, and OS/2.

Ian correctly points out that Avalon is more than just eye candy [link fixed]. I'm glad he made this point - all the flash in Avalon is really about providing easier ways to have computers interact with people (both on the input and output side).

One point that I have to disagree with, is this unnatural belief that everyone seems to have that it's not code if it has angle brackets. I hear people say this about XAML, HTML, XSL/T, and more. Just because it's markup doesn't mean it isn't code. Pure HTML + CSS, that I would classify as much more "document" than code... XAML and XSL/T, those are both pretty clearly in the code space. What is the line between Perl, C#, XAML, XSL/T, etc?

The key aspect isn't about if the language is declarative, imperitive, a mix, or what... the key aspect is the abstraction layer that you program to, and the number of constructs that you have to understand to intepret the code. XAML is a declarative abstract language with a very few number of constructs... all making it simple to understand (hopefully).

The declarative thing is nice (especially for tools), and I think it is a key aspect. But declarative isn't some magic powder... i look at looping constructs in XSL/T and I get truly scared... it is often better to have a combination of declarative and imperitive code that try to go with a "pure" declarative model.

Jon posts hist own comparison of MXML and XAML, to which Rob responds...

The CSS debate was a huge one internally, and in the end I think you will find visual triggers, timelines, and visual trees to be a powerful way to change the appearance of controls... One of my big issues with CSS is that it really only works for "already known" customization points. With VisualTrees you can specify arbitrary new appearance using vectors, images, video, text, etc.

In my previous post I don't think I was clear about the methodology that Avalon uses to hack (err, customize) the XAML parsing. This caused Pete Cole to observe:

"That a hack is 'by design' doesn't make it any less of an inelegant, unsatisfactory hack. This does explain some of the bizarre syntax I have previously complained about. One wonders if the implementation of XAML is becoming like writing Word Processors - you end up putting in kludges/hacks in the code to cope with particular strange cases. That's OK a) the hack works and b) its invisible to the 'user' (they just see the programming formatting correctly as they expect) - hacking implementation of a 'programming' language ain't going to work." [Pete Cole]

The interesting to note, it is actually the Style object that implements the custom parsing and serialization of markup to support the "as use" syntax. This interface is documented and discoverable (both by tools and developers). In addition any component can implement the interface and customize their parsing.

Hack, maybe. Invisible, no.

Marku (over at Codito ergo sum) has figure out that XAML is really a thinly disguised build engine... heh heh... Seriously though, it is a good observation that XAML is really just a way to persist a set of CLR objects (of course, a specific set of objects with a specific gramar... not to be confused with a general purpose serialization engine... )

From Chris Sells...

"Marc Clifton, author of the MyXaml open source project, publishes a series of articles exploring opportunities for improvement for the Avalon architects to consider:

• Is Microsoft Bollixing Up XAML?--a look at "tag names are class names"
• Is Microsoft Bollixing Up XAML? -- The joys of VisualTree
• Is Microsoft Bollixing Up XAML? -- The case of the missing collection
• Is Microsoft Bollixing Up XAML? -- Decorating the house of cards"

I hate to defend stuff, generally I like the debate more than one sided... hopefully Marc will hear some of my responses and respond...

First, generally about style. Yep, Marc, you are right Style is messed up. Before we dive into the tag names are class names issues, lets address "Set"... right now it looks like we are fixing that one in a future release (I say looks like because of the standard caveats, etc... current plans always subject to change and still looking for feedback from customers, blah blah...).

The tag name issue - which for style we call "As Use" syntax - was a concious decision where Avalon broke the XAML rules.

Yes, as we have said many times, XAML is broader than Avalon. Don Box and I have shown XAML being used for console apps and more. In this case, Avalon decided that the markup model for style, strictly following the XAML rules, would have been horrible.

The problem starts with cloning. Since styles are effectively defining templates that need to be applied to multiple elements, you have the issue of defining what things need to be copied, and what can be assigned. In early builds of Avalon we used an implicit cloning model. We would create an instance of the element tree and then clone the tree, using several models for accomplishing this. It turned out not to work very well.

As part of the Avalon rearchitecture last year we moved to an explicit cloning model - enter FrameworkElementFactory. The element factor was an explicit object that would create new instances of another class and apply that style to it. Hence we could now create elements in a reasonable fashion. Of course, the markup ended up looking horrible:

<Style>
    <Style.VisualTree>
        <FrameworkElementFactory Type="DockPanel" ... />

So we came up with an alternative - what if Style had special parsing logic (by implementing an interface) and would basically switch the parser over from generating elements, to generating factories. Ah... now from an imperitive code model, we had explicit cloning, but from a markup model we had code you could understand. We then applied the same hack (uhm, i mean design) to the element explar - which gave us "<Button Background='Red' />"

I agree completely that the style tag breaks a bunch of XAML rules, and this was by design. The correct way to parse XAML is to instantiate the appropriate CLR types and inspect them for the various interfaces (IAddChild, IParseContent [or was it IParseLiteralContent?])... XAML is a way of binding XML to CLR objects.

And for the last bit - the magic missing collections... here is a continued debate on the Avalon team. Having a collection specified for every tag is a pain, so we introduced IAddChild as a way for a specific object to control the parsing of child elements and text. If we are using this interface too much, we should fix it - however the interface (and capability) is needed to support the final leaf nodes of the tree - eventually someone has to consume the text nodes in the XML document ;-)

Anyway, some of the issues that Marc brought up we are actively addressing, some we think are there by design... regardless, lets keep the conversation going and keep the feedback coming... we are listening!

My latest article seems to have appeared up on MSDN... The Blinking Lights Division is this month's (or bi-month's) column in Inside Avalon...

Wesner has been spending time with color, the good old color from WinForms. Interestingly enough, there are reasons for the odd behavior he describes...

When working on WinForms and ASP.NET we really wanted to unify some of the system types, and color was a pretty problematic one. The issue was that ASP.NET wanted to allow all the oddities of HTML (including the ability to use bogus or out of range values) for color, while WinForms wanted to allow all the oddities of User and GDI+ (including system colors that represent a logical color). The solution - lets to it all!

So the Color class was born.

We debated a lot internally if Color should be 64-bit scRGB or 32-bit RGB... in the end GDI+ (if i recall correctly) ended up punting on full 64-bit support for color, however we knew in the future they would want to move there. The internal data structure of color therefore uses a 64-bit value to store the color, but only ever utalizes the first 32-bits.

Next, to support the various ASP.NET round tripping issues, we needed to store the string name of the color.

Finally, we have a state bit to determine what is determining the color - basically is this a natural RGB, known color, or named color. Known colors are just the magic colors that are part of the web and win32 built in color set (Red, ControlText, etc.). We wanted to track the known colors both for dealing with the whacky Win32 system colors, and to preserve the knowledge that a color was specified as "red" not as 255,0,0.

That is what we have today - a big color class that can do a lot, but has a lot of idosyncricies...

In Avalon we are moving to a full 64-bit color engine (native scRGB support) with support for multiple color spaces (you can specify colors in CMYK, etc.). Our color object won't be shared by ASP.NET, so we don't have some of the name based stuff that we have to worry about, and right now our plan is not to support Win32 system colors - but rather to solve the same problem using our styling and resource system to have a more natural and evolvable system instead of the magic colors.

A couple points...

1. Why didn't Nikhil tell me he was doing something this cool?
2. Yes, Nikhil is the guy that wrote "Web Matrix" in his spare time
3. Nikhil is one of the few developers that I have met that is also a great graphi designer

Check out his very cool bexier spline designer...

Rory chimes in on some people saying that XAML should go... Of course, if I said something like "Just because you don't like the fact that Microsoft created a new markup language, you want to rip it out and replace it with something else. Did you stop for even a moment to consider what a monumental task that would be? Why don't you just ask for someone to repaint the Empire State Building? Or have it moved a block over? Or transported to Sweden?" people would just assume that I'm lazy and don't want to do the work...

Ryan is doing too many cool things to link to them one at a time... Just subscribe to his feed and check out the cool Longhorn (and Avalon!) stuff he is writing...

Tim comments on the London ISV event [via Scoble]... "I had wondered whether Microsoft might rewrite MSHTML in managed code, or else create a Longhorn web browser that converts HTML to Avalon rich text. Chris said no. He said that MSHTML is a complex body of code which does an extraordinary job of rendering even malformed HTML. Since the Internet works on the assumption that this kind of web page renders successfully, and since there are so many quirks and workarounds in MSHTML, Microsoft's developers did not dare to replace it. I hope I'm representing Chris's comments accurately. In essence, it suggests that IE will remain broadly as-is, well, for ever."

Of course, "for ever" is a mighty long time... but I can say for certain, MSHTML is a complex body of code, and as with User32, GDI, etc., we will think long and hard about the application compatibility bar before we start thinking about rewriting that code... But, as James Bond says, "Never say never"...

If you are intersted in where we are headed with XAML, you should really read Rob Relyea's blog... in one of his latest posts he outlines one of the debates we are currently having about how we want to expose complex properties (like Brush) in markup...

It's taken me a while to wrap my head around this whole service orientation thing, and this indigo thing, and... well, everything. Reading Dare's post about Objects and Messaging I can really see how people get this stuff confused. In ObjectiveC all method calls are really sending messages (in the implementation, I believe they really do send messages)... so, does that qualify as service orientation?

Well, remember the 4 pillars of service orientation:

1. Boundaries are explicit
2. Services are autonomous
3. Services share schema and contract, not types
4. Policy based compatibility

None of these actually say that messaging is part of service orientation. Messaging is one technique to accomplish some of these goals, it isn't a fundamental tenet of service orientation.

"What excites me is the possibility that generics and other new CLR constructs as they come will also be integrated into the OS. I have not really seen any generic mechanism used at the API level in any operating system, since generics often were a compile-time feature, not a run-time feature as it is in .NET." [Wesner]

We are spending a lot of time these days debating generics in WinFX... generics will be in the CLS for Longhorn, so we are free to use them. Right now there is purely a process/engineering issue where we need to get all the various pieces together to make generics work (NGEN, C++, etc.)... obviously in the PDC build there wasn't a lot of generics, but hopefully in future releases you will see more generics in the APIs...

Martin has an interesting bliki entry on commands... we are trying to work through the design of Avalon commands internally... once we get something solid enough, I'll try to post some of the design docs...

Wesner has noticed that XAML can be used pretty broadly as a document format "If application developers start writing document-based applications that follow the Avalon model of deriving new classes from existing elements, or even simply reusing existing elements, and turning on some of Avalon's designer services, XAML could quickly become one of the most common file formats."

In fact, if you look at the container support in Longhorn (System.IO.CompoundFile, if I remember right) there is more than just XAML in here. With Longhorn we are doubling down on OLE compound files to have a good way to have complex documents with rich metadata.

Rory had an epiphany... Indigo is key. As Don says "No program is an island".

Rob Relyea (master of XAML) is back in force on his blog, and started with a great post about XAML compilation...

Windows and Office have often had an interesting leap frog-ing behavior, and Wesner points out that with Longhorn we are pushing the envelope in Windows...

Interestingly I think going forward we will see more innovation from application vendors - Longhorn will give developers so much more to build with that they can build much more distictive looking appliations.

For those of you that still want more... Here is the latest .NET Show, include Don and I in another reprise of the Lap...

Don & I have finished our presentation now... I did my 10 minute keynote demo (B) and then the first hour of the presentation was focused on the fundamentals (I did the talking, B-)... after lunch we did 2 hours to cover the three pillars of Longhorn (A)... overal, I guess I'd give myself a B+ rating then...

We talked with press for about 30 minutes after Bill's gig, then hung out with the delegates (attendees) for another hour or so - it was great fun. I've really enjoyed the UK gig, however I wish I had done a better job on the first hour of the talk (a B- is below what I'm willing to accept <G>)...

Anyway, tonight is the Blogger's dinner at Masala Zone - we tried to organize a pre-func at a local pub, but unfortunately we never choose a venue... looks like we will have a pretty good showing (40 comments at this point, something around 30+ people claiming they are going to show <G>)... Don's bet is we will hit around 20... still sounds like it will be a smashing good time!

As a side note - Megan (my wife) watched me present for the first time ever today. Very interesting. She's going to be at the blogger's dinner tonight also. An interesting experience to merge facets of your life like this <G>

I had a meeting at work today where I was asked to explain a bit about Avalons multiple trees, events, property system, resources, styles, etc... I didn't quite get to all of it, but I thought I'd share some of my explanation here...

Pre-reading... The Avalon rearchitecture Part 1, Part 2, and Part 3.

Trees

Avalon has One Tree, right? Well, that was what I claimed in a previous post... Of course, by now you should know that I firmly believe in the saying that "facts obscure the truth". From the view of the Avalon rearchitecture we did go down to one tree, however reality is never that clean.

Avalon as a "visual tree". That tree is a tree of objects that derive from MSAvalon.Windows.Media.Visual. Visual can be conceptually thought of as a rendering surface. In fact there are several types of visuals (2d rendering, 3d rendering, video, etc.). The base element class - MSAvalon.Windows.UiElement - derives from Visual also. Thus, the "visual tree" is a tree of visuals, some of which are also elements.

<LowLevelDetail BoredomFactor="High">
The "visual tree" is actually not really the display tree. The managed visual objects are compiled (converted, rendered, whatever you want to call it) into a "composition tree". This is built up of unmanaged "comp node" objects that are what we use for low level rendering and animation. It is these comp nodes that can animate and render at display refresh speed (yes, that means updating 60Hz+). No user code (or managed code) ever makes it to the composition tree - this is critical to maintain glitch free video and animation (not because of the GC or anything... the design of the composition tree could be an entire post...)... Communication between the composition tree and the visual tree is done through two one way message pipelines - one inbound, one outbound.
</LowLevelDetail>

Within this visual tree we needed to splice in things like a <Bold> or <Paragraph> - which can't be simply represented as a single visual (imagine a bold or paragraph that splits multiple pages). To facilitate this, we created a notion of the "logical tree" - that is a parent pointer (and children) that are not associated always with the visual hierarchy, but can have non-visual nodes in the tree.

Events

Events come in three flavors - preview events, bubbling events, and simple events.

Preview events (like PreviewKeyDown) travel down the tree from the root to the target element. Imagine if you press the key "A" inside of a textbox. The window at the root of the tree will first get the PreviewKeyDown event, followed by each element that is a parent of the textbox, until eventually the preview event makes it to the textbox.

Bubbling events (like KeyDown) travel from the target up to the root element. Again, imagine the textbox and your press "A". In this case the textbox gets the KeyDown event first, followed by each of the parents of the textbox, until eventually the event makes it all the way to the window.

Simple events (like TextChanged) only are raised on the target element. Almost all the property changed events are simple events (also called "Direct only" events).

Events are dealt with in two stages - build route, and invoke. Build route basically traces the path from the target element to the root of the tree. Then, during invoke, each element in the route is invoked with the event - either starting at the begining of the route or the end. The route will include elements from both the logical and visual tree - thus, you can handle the TextBox PreviewKeyDown event in the Bold element that is wrapped around it!

Properties

The Avalon property system - called the dependency property system - was originally designed as a way for our engineers to reuse code. We found that all of our properties wanted to share a great deal of features; inheritence, styling, change notification, attached storage, data binding, validation, etc. We didn't want to duplicate all the implementation of this for every property, so we had to find a way to make this work consistently across the platform. In addition, we didn't want the consumers of these components to have to learn a new concept, so we knew that we needed to leverage the existing CLR property system.

Dependency properties are defined with a token - the DependencyProperty - that uniquely identifies the property and lets the definer specify the various services that they want associated with that property. The definer then implements a CLR accessor for easy use. Thus, when you say "button1.Backgorund = Brushes.Red;" the dependency property system is actually invoked, and allowed to provide the implementation of that property.

This is a much more abreviated version of the discussion, but probably long enough to bore you all...

Jeff Bogdan is one of the other architects on Avalon... He and I signed up to write a column on MSDN, he got to publish the first article in the series... Hopefully Jeff will keep on me to make sure I don't let this die like the last series I told MSDN that I would do! :)

Michael Earls has stirred up a lot of responses to his plea for Microsoft bloggers to talk more about the here and now...

"Here's my point, enough with the "this Whidbey, Longhorn, XAML is so cool you should stop whatever it is you are doing and use it".  Small problem, we can't.  Please help us by remembering that we're still using the release bits, not the latest technology." -- Michael

Dare, Don, Harry, and Scoble have responded...

Michael responded to the responses...

"My plea was not so that the advanced developers of Microsoft would stop posting about new technologies, it was merely to get them to remember where we're coming from and take a few extra seconds to connect the "now" with the "next"." -- Michael

I think this clarifying point is a great one. I write my blog to talk about what I do all day, whether it is working on the house, driving at the race track, or building Longhorn. My goal in my blog is not to be a corporate mouthpiece, but rather just communicate with an entire ecosystem of people out there (of course, this could cause another round of blog-examination for me...)

Michael's comment is valid - connecting the here and now with the future is absolutely key. Not just for blogging about Microsoft and/or technology, but when talking about almost anything. One of the great skills of a presenter is to grab the audience, typically by describing the here and now, and how whatever they are talking about will move you from the here and now to a better future.

I worked on WinForms, .NET, and Visual Studio for years (well, my time in Visual Studio was mostly in the VJ++ team, which, well, anyway...) so I should spend more time talking about how WinForms, etc, contribute to the design of Longhorn... and how code and developers can migrate forward.

I don't intend to stop talking about Longhorn - it is what I work on every day (regardless of if I'm in the office! <G>) - it is part of my DNA at this point.

Interestingly CLauer thinks we develop Avalon on Windows XP... "My understanding is that the development teams that are working on WinFS, Avalon and Indigo are neccessary working on today's systems, Windows XP to name it. So, obviously, current pre-alpha builds of each of these three Longhron pilars have to run on Windows XP. I do not understand how it could be otherwise."

While the build lab does produce builds compiling on a shipping operating system (I actually don't know if they run Windows Server 2003 or Windows XP, but I think it is Win2K3?), developers run Longhorn.

If memory serves about 14 months ago it became a requirement that we dogfood Longhorn to use Avalon. For the first year or more of Avalon's existence Windows XP was the base we built on, however as we added more dependencies, and got more people using the bits, we could no longer support using WinXP as the dogfood environment, so we all upgraded to Longhorrn.

Of course, trying to develop a component and have your main dev machine be running a daily build of a pre-Beta operating system is quite a challenge. Some days you come in and upgrade to the daily build only to find that some core part of the OS decided to break that day. Of course, this is one of the ways we try to drive quality - by having the developers feel the pain if something is broken, generally it gets fixed very quickly. In addition even our VPs dogfood Longhorn, so you can imagine that occasionally there is a lot of pressure to fix something if their machines break!

The answer to the question is a little of both - we compile the new version of the operating system on both released Windows and Longhorn, but we only debug, test, and run (obviously) on Longhorn.

Sami did some DLL hacking and got Avalon running on Windows XP... I missed the post, but someone internally forwarded me that he was asking what I thought of this. I guess there are a couple points here:

Avalon is a Longhorn only feature.

One of the big new changes that isn't yet in the Longhorn builds is the new video driver model. Once that goes in, you really won't be able to run Avalon on XP. In addition when the desktop composition stuff gets turned on (it wasn't in the PDC handout build) there will be a tight dependency between Avalon and the Longhorn User32.

As with any single feature in an operating system, you can manage to get it running elsewhere. If you really wanted you could probably copy the Longhorn Kernel32 over to an XP machine, however eventually you will need to copy most of the OS over to XP to make all the features work.

Early on in the Avalon development we actually ran Avalon on XP all the time (there was no real "Longhorn" yet). For more than a year now Avalon was only running on Longhorn. Now that we are pushing towards Beta 1 the number of inter-dependencies between components are increasing.

In short, while you may have been able to get this working on the PDC build, this won't be possible in the future builds.

I guess my advice to Sami, I wouldn't bother publishing the steps needed for this. Not only is it a completely unsupported configuration, it is also something that won't work going forward.

Wes is lamenting the lack of a formal doc/view framework in Avalon... I can say that as of today we don't have plans (at least on the Avalon team) to produce a doc/view framework ala MFC (as with all statements about products these are subject to change at any time, especially with feedback <G>).

A couple key points that Wes makes:

"In MFC, we start with a full implementation of a document-based application that does nothing; all the infrastructure (opening, edit, printing, windowing, OLE, etc) is in place, and developing an application involves simply modifying the do-nothing application to do something. The best thing about this approach was that almost all the testing for the the infrastructure code came for free."

However, he continues, we took a step back in WinForms:

"In WinForms, we lost that, although there is a project underway called Genghis to restore the missing glue tying all the framework objects together into a document-based application."

Genghis creator Chris Sells (who is now a 'softie) often gives me grief for our decision not to do a doc/view framework.

At this point, it is all about resources. In Avalon we are rebuilding the core infrastructure for the presentation platform in Longhorn. We have a new driver model[1], graphics stack, control library, and application model. All of this with a unified approach allowing for integrated documents, ui, and media. This has been an amazing undertaking. Prior to PDC 2003 we had already spent over 2 years working on Avalon.

The issue is that we don't have enough time or resources to do everything, and right now the doc/view framework has fallen off of our plate (it was considered).

I've talked with people from the C++ team (that own MFC) and the .NET Client team (that own WinForms) to see if they have the resources to build a doc/view framework on top of Avalon. The nice thing about a doc/view framework (going the way that MFC did) is that it can be layered on top of a core framework. No news yet as to if they can or will do it, but we are listening to the feedback and trying to understand how we could tackle this.

"Other than the strange Objective C syntax, I found much to my liking in Cocoa. I was surprised to see support for name-value pairs, which look similar to Dependency Properties in Avalon. Cocoa does use the familiar MVC paradigm, with the standard NSController, NSApplication, NSDocument, NSWindow, NSControl objects. NSWindow, NSApplication and other "NSViews" derive from NSResponders, which implements the "Chain of Responsibility" design pattern. Even though, I have never seen Cocoa before, I know how it works because it follows the same pattern as every other framework. I know that Cocoa's NSResponder is the same as TCL's Bureaucrat, which is the same as MacApp's EventHandler."

I've spent a small amount of time programming in Objective C against Cocoa, and I also found it very elegant, but overly complex to do simple tasks. My personal believe is that MVC paradigms should always be layered on top of a simple object oriented component based framework. There is a large class of developers that don't understand MVC and you can never hide complexity completely.

"But my fear is that, while document-based applications based on Avalon may become more flashy, they will look more like web-pages and less like Office-style applications. I not getting the sense that Avalon is paying attention to the traditional document-editor application."

I disagree with your view here, but I totally understand the concern. Right now we are trying to crawl before we run. Avalon has a complete editing infrastructure with extensible mechanisms for adorners, backend stores, selection, etc. With a couple simple controls and properties you can create a editing surface for writing documents, media (animations, vector graphics, etc.), and ui (traditional forms). While we do lack the doc/view framework as an intrinsic, we are spending a lot of time trying to make sure that the platform provides the core services to allow for a great document editor...

[1] All WinXP drivers will continue to be supported, rather there is a new driver model that will be more robust, blah blah...

Don Park has an alternative to reusing the XML hierarchy for visual hierarchy for things like XAML...

 <XAML>
  <Window ID="root">
   <Window.Background>Blue</Window.Background>
 </Window>
  <Button ID="mybtn">Hello World</Button>
  <Insert object="btn" into="root"/>
  <Center object="btn" to="root"/>
  <Move object="btn" x="10" y="20"/>
 </XAML>

We are currently having a big debate internally around the usage of Uri and String in our APIs.

Use Uri not String

URI cannonicalization and escaping is very complex and people always get it wrong, so you must have a single codebase to do the work. Beyond that, converting from each form of a URI can introduce artifacts, so once you resolve (my shorthand for canon, escape, etc.) the URI you can really never go back to a string and try to resolve again (not precisely true, but basically). In Internet Explorer the resolving of URIs was a huge source of security issues, so we can't repeat that mistake in WinFS.

Offer both Uri and String

Using a single codebase for resolving URIs is great, just don't make developers suffer by having to create URIs everywhere. Developers think of URIs as strings, not complex objects.

The pattern should look like:

class MyComponent {
    void SetSomething(string uri);
    void SetSomething(Uri uri);
    Uri GetSomething();
}

The idea being that developers can call either version of the API. The implementation of SetSomething(string) would do nothing more than new up a Uri and call SetSomething(Uri).

Use Uri not String

The problem with the above pattern is that in a component based system you have people calling components through multiple layers. If internal MSFT develoepers (and third party component developers) start calling the string version, we get back into the "string -> uri -> string -> uri" world which introduces loss of data (hence security issues).

Offer both Uri and String

We should just have a rule that says once you convert a Uri to a string, never go back. Then developers on the leaf of a component hierarchy would do the conversion, and it would transfer back.

Use Uri not String

Ahh, that is a great view, however history has shown us that doesn't work. It isn't possible to guarantee that no one converts back to a string, and therefore we will ship a bunch of components with this.

... And the debate continues to rage...

As has been mentioned many times before, XAML is a generic programming model for working with CLI object trees. Don even wrote a console application in XAML. As part of our effort to really nail down the format and rules for XAML, we are doing some internal design reviews of XAML. Right now we have assembled Gudge, Don, Rob, and myself.

The four of us came up with a long list of our pet peeves and issues (for example, using a PI for the Mapping directive makes it impossible to embed XAML inside of a SOAP message).

Rob is the program manager owner of the XAML spec, and is looking for anyone out there that has strong opinions about some of these issues to make comments on his blog... What is missing from or broken about XAML?

We gave out bits at the PDC to ellicit feedback from people, Here is an opportunity to directly spout off to the owner of the specification of XAML!

Interesting... Drew Disects Avalon...

Joe dives into the details on the visual system in Avalon.

Markus has started blogging.. Markus is working as a program manager on the Avalon Performance team... yes, he has a lot of work ahead of him :)

Adam Ulrich commented on my last Avalon rearchecture post:

"Mustn't controls have some inherent _general_ knowledge of their visuals?

My example: a scrollbar must know that it has some logical element that relates to visual elements that equate to a thumb, and that it can move along logical element that relates to visual elements that define some path."

Someone once told me that facts obscure the truth (actually many people have told me that)... There are several (small number) of controls that must have deep knowledge of their visuals. The slider portion of the scrollbar needs to have knowledge of it's visuals, although the scrollbar doesn't. The scrollbar istelf is composed of a repeat button (line up), slider (which is the well and thumb), and another repeat button (line down). I don't think in the PDC builds it's quite this clean, but this 3 controls will be (hopefully! <G>) the way we build the scrollbar later this milestone.

Generally an element should have contracts with it's visuals with commands, databinding, attached properties, and named styles.

Commands are how the repeat button should bind to the LineUp/Down command on the scrollbar. Databinding allows you to bind the value of the scrollbar to the value of the slider nested within. Attached properties are used to allow the element to locate a child within - for example the ListBox looks for the ItemsControl.ContentOwner property on a child element, and that element becomes the parent for all the generated content from the list items. Named styles would be the way that you could replace sub sections of a control, this would typically only be used on more complex controls (like a data grid, or something of that ilk).

"Rich Everywhere" is a phrase I like to use to talk about Avalon. We want to enable every control to support any rich content, interaction, and presentation. Part of being rich is actually having a system that people can understand, tool, and build these great experiences on the platform.

In DOTNET the number of customization points brought about a big problem. You could customize the look of an element up to a certain point, but then you would have to completely change your programming model to use the presenter. Presenters couldn't be authored in XAML, and you weren't able to create elements dynamically inside of the presenter, so you ended up being limited to using low level drawing calls.

ECM

We had to solve the notion of "rich content". There is this tension between flexibility and programmability. For the VB developer, we want to enable something as simple as:

Dim b As New Button()
b.Text = "Hello World"

For a web developer we want to enable something as rich as:

<Button>
    <GridPanel><Video ... /><Text>Hello <Bold>World!</Bold></GridPanel>
</Button>

The problem was to do both with a single object model. We talked about having two buttons - a "simple" and a "rich" button. No. We talked about having multiple properties - "Text" and "Elements". No.

Then the idea came - borrow some pages from WinForms and ASP.NET, mix in some new twists, and viola!

ECM (I forget what the abreviation stood for originally...) was the idea to have a mechanism to take arbitrary CLR objects and convert them to UIElements. If the CLR object happened to be a UIElement, we were done. If it wasn't, then we could create a visualization for that data item using TypeConverters, ToString, or a data style. Basically that means that button now has a "Content" property, that is of type "System.Object". If you pass a string in, we stuff that string into a text element, and if you pass a GridPanel in, then we just display it.

Controls have 3 flavors - No content (Border, etc.), Singular Content (Button, etc.), Multiple Content (ListBox, etc.).

You can mix and match; a Menu has a header (Singular Content) and a list of menu items (Multiple Content) - so we have something called a "HeaderedItemsControl"...

Only use elements

When I talked about simplicity, I mentioned that we doubled down on element composition. Another side effect of this was to unify the programming model for all customization. You could now completely change the look of an element all declaratively in XAML.

Once we have this model, we now have a tenet that all controls must not have inherit knowledge of their visuals. This allows developers to completely change the look of any built in control without having to change the behavior at all.

Part of the original goals of Avalon was to leverage the power of the GPU. The idea of hardware accelerated 2D graphics has been around for a long time, but it hadn't really taken off yet (remember, we started Avalon in early 2001 [fixed date]). Today it seems pretty obvious that leveraging the GPU for 2D is the right path, but at the time that we started there was a lot of concern about the type of hardware that we would require.

One hugely controversial decision that we made early on was to write Avalon in managed code. From a platform component, the CLR is still immature. It's getting better by leaps and bounds. The work to integrate the CLR into Yukon, moving the entire system to 64-bit, and the work in .NET 1.1, and Whidbey have made the system amazing. Again, when we started .NET was just first released in beta. Also, the development teams working on Avalon are used to the C and C++ toolset that they had been working with for the past twenty years. The decision to move to managed code was a fun process, but that I'll leave for another day.

The DOTNET tree was not measuring up to performance goals. The startup time was slow, but more troubling was that the scalability of the system - the number of elements that we could create and manipulate was just too small. To acheive our goals around richness we would need a system that could scale to tens of thousands of elements, and we were only a couple thousand elements displayed in a reasonable performance. Layout was slow, working set was huge, it was a bit scary.

Before we began the rearchitecture we spent a bunch of time focusing the entire team on performance. We started doing deep analysis and looking at how the system hung together. We created two virtual teams to try and drive the performance effort - a bottoms up team that was focusing on tuning components and code, and a top down team that was looking at the design of the system to see what we could do architecturally to make the system faster. When we started the rearchitecture effort we took the data from the bottoms up and top down team as baseline data.

We had several simplifications that we hoped would contribute to better performance:

• One tree
• Simplified property engine
• CPS/DPS

One tree

By unifying the tree, we felt that for UI scenarios we would see a huge performance benefit. Specifically you would only have a single node for a element (like a Rectangle) where as before you might have up to 3 objects. Also, the connections between the elements would be much more simplified, there was no need for back pointers from the visual tree to the element tree to managed input, etc.

Simplified property engine

The original property engine from DOTNET was designed to support a very complex expression evaluation system, track dependencies, deal with complex CSS-style rules, etc. Part of the rearchitecture was the decision to cut several of these features to make the property system much simpler, and therefore (hopefully) faster.

CPS/DPS

The DOTNET layout engine, using presenters, was a single monolithic system. That system handled everything from a single absolute X,Y layout up to a complex paginated table. The issue was that for all the simple UI scenarios we were doing a ton of work for relatively no value. The solution was to create the "Control Presenter System" that would handle basic UI layout, and a more advanced "Document Presenter System" that would deal with the rich pagination and typographic layout.

By the time we finished the design for all of this we had actually completely removed the concept of presenters from the system, but the name CPS/DPS stuck for the architectural design. Funny how those things happen.

As we rolled out the architecture proposal the performance aspects of the proposal were probably the most controversial. No prototype can accurately represent how a system will behave in the "wild", and our performance team had previously heard promises of large changes helping performance. Unfortunately we were never able to get a 100% accurate measurement of the perf gains, but we had to make a decision. As with a lot of decisions, you never have all the information that you would like to have.

During the implementation and conversion to the new architecture we hit several perf snags. We didn't get any huge working set improvements (we are still working on this today), however we did achieve our scalability. The system (in our tests, no warrenties implied, etc.) scales linearly as you add more elements. The largest I've done is a couple hundred thousand elements... it was really slow, but it didn't crash.

Best performance bug: I forget the root cause, but when you ran a specific test the working set of the app would hit around 1.2GB (yes, gigabyte!) before the app would die.

We have made a couple other changes to the system since the big rearchitecture - the new styling system is one example - and we continue to try and make the system faster. The PDC bits are clearly way below what we want for performance.

The Avalon rearchitecture that happened earlier this year was motivated by several things (in my mind... hmm... another time for a disclaimer - as with anything that happens each participant will have a slightly different version of the "truth". As time goes their becomes more and more difference between each persons view. So, all that follows here is my fuzzy recollection of what happened, and shouldn't be missinterpreted to be the only "truth" of what happened...)...

• Simplicity
• Performance
• Flexibility

Before I start, I need to tell you about a few new names - DOTNET and WCP. Our old architecture bits lived in a source tree where the root name was "DOTNET". I wasn't on the team when this name was choosen, but I'm guessing that it was picked because the Avalon team was an early adopter of managed code, and so they named the directory after .NET. When we began work on the new architecture we picked a new directory name, "WCP". When I refer to WCP and DOTNET design, these are nothing more than the names of two directories in our build tree - these aren't product names, no warrenties apply, blah blah...

Simplicity

The DOTNET model had some pretty severe problems with complexity of the design. Their tended to be 7 ways to do anything, and many of them tended to be massively complex. The reason for this was pretty simple - we had 400 people working on the product and all of them were trying to build the "best" of whatever they were working on. The best example that I have is how to customize the appearance of your control... we had templating, presenters, element composition, visuals, etc... I can't remember the complete list, but at one point there were actually 7 full featured ways to customize this.

Probably the most maligned peice of technology in DOTNET was this thing called "Presenters". Presenters were a very well thought out, robust, and complete technology. Basically it was an abstraction over layout and rendering, which allowed for any control to have any display. Presenters allowed for pluggable rendering, pagination, virtualization, etc. They allowed for a clean separation between the visual tree and the element tree.

Ah, which reminds me - we had a lot of trees at the time. There was the element tree which was where your buttons and listboxes lived, and the visual tree which was the retained mode managed scene graph, the presenter tree which was a "kinda" tree that was made up of the presenters and their relationships  to their child presenters (basically an element may or may not have an element. For example, text formatting elements like "Bold" didn't have a presenter, they used their parent presenter), and we had a composition tree, etc.

Presenters where this great thing, however they were very complex to use, and they had a fairly different design center and programming model than the rest of the system.

Our solution to simplify a lot of this in WCP was to make a couple big bets - Element composition and a unified tree.

Where in DOTNET we had a separate tree for elements, visuals, and presenters - in WCP we have a single tree of nodes. For various reasons we have multiple "views" on the tree - Logical and Visual - they actually share nodes. Some people find this 1.5 tree system to also be confusing and we are still looking at ways to simplify this.

Element composition was the biggest bet by far. We are now using elements for all display composition. When you see a button in the PDC build, there are actually 17 elements inside of that button. Rectangles, Borders, DockPanels, Text, etc. Using a single feature for all rendering allowed us to remove some of the duplicate ways of customizing the display of the elements. In addition, we settled on a single styling system that included the ability to style the "visual tree" of any element.

To be continued...

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...

I still owe a code sample about using DependencyObject from a previous post (I will write that!), however I'm curious what would interest the couple people out there that read this... besides my boring opinions about the universe, and my adventures with aquatics, what do you want to read about?

1. Design issues that we are tackling for the next release of Windows (Beta 1?)?
2. History of the PDC bits (how we formed Avalon, etc.)?
3. How to code with the PDC bits?
4. Some other topic?

I'm happy to do a combination of all of the above, or skip them all... what do you care about... I just don't want to becoming boring... that would just be sad.

Rob gives the scoop on why XAML is XML...

Sam asks "the ability to modify the rendering and content of the document on the fly?  Isn't that lost by a compile to bytecode approach?"...

Sorry for the delay in responding, Sam's post has been sitting in my inbox while I found a couple minutes to respond... There are lots of comments on Sam's post directly that respond to this, but I thought a more detailed answer might prove interesting for everyone...

First, as people pointed out there is a difference between XAML (the programming model) and Avalon (the presentation system).

Using XAML, you can invoke the parser at anytime:

DockPanel d  = (DockPanel)Parser.LoadXML("<DockPanel xmlns=\"http://schemas.microsoft.com/2003/xaml\"><Button DockPanel.Dock=\"Fill\">Hello</Button></DockPanel>");

(Appologies if the code doesn't compile, i'm not sitting in front of a Longhorn machine right now)

However - that XAML can't contain any def:Code fragments, because at this time we don't do dynamic compilation on the client during parsing.

In addition to dynamic execution of the compiler, you can also programmatically create elements:

DockPanel panel = new DockPanel();
Button b = new Button();
panel.SetDock(b, Dock.Fill);
b.Content = "Hello";
panel.Children.Add(b);

Of course, you can also set events:

b.Click += new ClickEventHandler(MyHandler);

In fact, the parser is really just doing a bunch of "new DockPanel" and "new Button" calls when it parses the XAML. XAML is just another view on code... You can do everything in code that you can do in XAML - and you can do it dynamically with a strongly typed simple programming model.

Don has a secret... He knows how to make XAML work for any object... I guess it's not a secret anymore.

Rob is a PM on the Avalon team. He owns the XAML spec. He also is a member of the Avalon architecture team (with me and a few other folks).

Rob has a blog.

See rob blog.

Blog Rob, Blog.

Rob's first task, to do some postings that cover some of the Avalon overview presentations that he has done in the past.

Hillel Cooperman, of Aero fame, now has a blog... with RSS (now <G>)!

Erik Arvidsson asked in a comment: "What was the reasoning for not making the UI elements extend XmlElement? Since XAML is supposed to be an XML language it would seem obvious that one should be able to use the W3C DOM."

Yet another often discussed issue internally. To start, lets consider the following markup:

<Window ...>
    <Window.Resources>
        <SolidColorBrush def:Name="MyBackground" Color="Red" />
    </Window.Resources>
    <Button Background="{MyBackground}">
        <myobj:Customer Name="Chris Anderson" />
    </Button>
</Window>

In the fabulous XML DOM I would get, of course, a bunch of nodes. The root node would be the "Window" tag, and would have children "Window.Resources" and "Button". Of course, we have already gone astray.

In XAML we recognized that properties (which can be attributes) often contain complex values (for example, the Resources property on the Window in the above example is actually a type of map/dictionary). However, sometimes they can contain simple values (like Color="Red" on the brush). Thus, you can end up with any attribute in XAML also being a compound property, which makes it a nested tag. Thus, these two are syntatically equivalent:

<Button Background="Red" />
<Button><Button.Background>Red</Button.Background></Button>

Which makes it problematic to use the XML DOM out of the box. In addition, lets flashback to that first example above - the SolidColorBrush is not actually a UIElement. While the Button and Window are both UIElements, the SolidColorBrush is just a CLR object. It would not appear in your element tree, and asking the Window or Button for it's visual children would never produce the brush. Second problem.

Finally, check out the "myobj:Customer", this is an example of a random business object (maybe a WinFS thing? maybe just something I invented) that I wanted to create in the markup. Since XAML is programming model for targeting arbitrary CLR objects, there is no requirement about the OM that these objects must implement to be serialized into the XAML (well, there are a few, but they are simple things).

Given these three things, we felt it would actually be confusing for developers if we implemented the XmlElement OM. The XmlElement OM is about traversing an XML document - the Avalon element tree can be persisted into an XML document, but it can also be generated from C#, your custom markup, or any other format that you dream up. In addition, using .NET 1.x you can serialize any .NET object into XML also - so that would argue that everything should derive from XmlElement (yes, I know that some people would applaud this! <G>).

Remember - XAML is just one of the programming models for targeting the Avlaon presentation classes.

There seems to be a lot of discussion floating around in my comments about "Dynamic XAML", which confuses me (I'm easily confused). No one thinks of "Dynamic C#" or "Dynamic VB", they are languages - it is the application that you create that has dynamic behavior...

Dynamic user interface can be easily created in Longhorn using Avalon in several ways:

1. Dynamic code
2. Conditional/Bound markup
3. Parsed-at-runtime markup
4. Projection based markup

Projection based markup

I start with projection, because I think it is what most people think of when they asked the question about "dynamic XAML". In the web world today you create projection based user interface. You do work on the server to determine what the static view the client should see (maybe with some interactivity in the form of jscript, etc.), and then you project HTML across the wire and let the (basically) dumb client render that logic.

In the web today there is this uneasy tension with DHTML (W3C DOM or IE DOM) and ASP.NET/PHP/JSP... Here you have a sever and client side programming model, both trying to produce dynamic results. You end up with this bizaree spaghetti code that spans between the tiers. You might do data filtering on the server, but allow for sorting to occur on the client to avoid round trips.

The question then is raise, with this new Windows markup "XAML", can you accomplish projection based UI? The simple answer - yes. We support parsing of markup on the fly.

However for interactivity the programming model for Avalon is .NET classes, which means you need to somehow get IL generated, or have an interpretted language. Today the JScript parser is the closest thing we have to an interpretted .NET language, but I know there are other interpretted languages out there.

Why have we not focused on interpretted or projection based UI? To put it simply - it doesn't scale. Smart client applications aren't really possible in projection based UI. If you look at any even moderately interactive application they have moved the processing logic to the client to leverage the power of the PC - Flash, Java, Anark, all do the logic on the client. Yes, there are some places that do dynamic Flash generation, but that seems to be a limitation that products like Royale and Central will solve.

Parsed-at-runtime markup

If projection based markup is only supported limitedly, then what about parsing at runtime? This is the old DHTML model of doing things like "document.Write" and "someId.InnerHtml='...'" as a programming model.

Avalon has a simple object model for our parser that will allow this type of programming. You can concat a string together, pass it to the parser, and get back a fully realized .NET object, viola!

Of course, parsing and string generation has it's problems - lack of type checking at compile time, performance, debuggability, etc. This model, like projection based markup, is supported - just not encouraged.

Conditional/Bound markup

Hopefully, eventually, I will actually hit one of these mechanisms for dynamic UI that we think is great. Well, wait no longer!

Using databinding, repeating, styling, triggers, frames, etc, for creating truly dynamic UI is the Avalon recommended way. People write "dynamic" UI today using VB.NET and WinForms that gets data from a database and presents it in a great format using DataGrids, etc. In Avalon we are evolving this and adding rich typography, template based repeating, and a new model for triggers and styling.

The nuts and bolts of this? Say that I want to create a news browser, I can create styles for the news objects (note, these are data objects, not UIElements):

<!-- Psuedo-code, I don't have a longhorn box handy right now -->
<Style def:Name="*typeof(NewsReport)">
    <DataElement /> <!-- I forget the exact name of this element... ? -->
    <Style.VisualTree>
        <DockPanel>
            <SimpleText DockPanel.Dock="Top" Text="*Bind(Path=Title)">
            <SimpleText DockPanel.Dock="Top" Text="*Bind(Path=ByLine)">
            <TextBox DockPanel.Dock="Fill" Content="*Bind(Path=Body)" />
        </DockPanel>
    </Style.VisualTree>
</Style>

Now, I could have another format for some other type of story:

<!-- Psuedo-code, I don't have a longhorn box handy right now -->
<Style def:Name="*typeof(ForSaleAdd)">
    <DataElement /> <!-- I forget the exact name of this element... ? -->
    <Style.VisualTree>
        <DockPanel>
            <SimpleText DockPanel.Dock="Top" Text="*Bind(Path=Title)">
            <TextBox DockPanel.Dock="Fill" Content="*Bind(Path=Body)" />
        </DockPanel>
    </Style.VisualTree>
</Style>

Here I could then have a listbox that contains an arbitrary list of NewsReports and ForSaleAdds, and each would be rendered according to the style - thus a WebService (or, heaven forbid!, a database) could return the content. These "data styles" can be associated with the class that defines the data structure also.

Remember The ListBox is really a generic repeating control, it isn't the same as the old scrollbar and horizontal list control. The ListBox in Avalon is more of a peer of the "DataList" in ASP.NET.

Dynamic Code

Finally, if dynamic markup doesn't solve this, you can go to the brute force traditional model for dynamic UI - write code. One of the goals with Avalon was to have a unified model that provided both a simple markup and a simple code based programming model. Thus, if you want to dynamically generate user interface elements you can simply write code like:

void ButtonClicked(object sender, ClickEventArgs e)
{
    someElement.Controls.Add(new Button());
}

Which provides you with unlimited flexibility.

Summary

My not-to-hidden agenda here is simple - dynamic applications should be dynamic on the client. The server should send data - either through web services, database access, or any other wire protocol - and the client should consume that data and generate UI. The model of a server trying to generate the correct display for a client is just broken.

My computer knows what my settings are, I don't need to server to guess them. The application on the client knows my screen resolution, DPI, color depth. It knows if I have a scanner, mouse, keyboard, tablet, printer, etc. The application on the client has full access to a powerful CPU, GPU, and hard disk that are dedicated to *me*.

We are past the world of generating static snapshots of display and blasting them down to a client. Most desktop computers you buy today have 2+Ghz CPU, >256MB of RAM, and a massive hard disk. Use them! Make your application be so engaging and productive for your customers that they want to buy it.

I'm a bit confused by the concern that Microsoft is somehow trying to threaten or take over the web with the introduction of a markup language to program Windows applications. XAML is a new programming model for the next release of Windows, code named "Longhorn". That's it.

Christopher Lord put it nicely: "One thing seems fairly clear: XAML will not threaten the web much, since the platform will only be on longhorn."

My goal is to provide the simplest and most productive platform for developers to build smart client applications on.

I've been getting hits from LonghornBlogs (which I like <G>), but I really wish my content just appeared there. I think LonghornBlogs should support an aggregation model (like PDCBloggers)...

Here are my links... Robert, can you make this happen? :-)

HTML: http://blog.simplegeek.com/categoryview.aspx/Longhorn
RSS: http://blog.simplegeek.com/BlogXBrowsing.asmx/GetRssCategory?categoryName=Longhorn

In the mean time, thanks to Andrej who keeps linking to me!

Neil says:

"People are looking for something familiar to compare XAML to, usually comparing it to XUL, since they are both XML languages for constructing user interfaces. They do have very different purposes though. XUL was primarily developed for constructing Mozilla's UI, and for constructing web oriented applications. It wasn't designed so one could write a better alternative to Microsoft Excel or Adobe PhotoShop. Thus, XUL builds on existing web technologies such as CSS and JavaScript. Web developers are familiar with these so the transition is much simpler and smoother. XAML, on the other hand, is a transition only for .NET developers since it contains things from there but contains almost nothing from the Web. The gap is much too large for web developers, which may mean that it may have trouble getting any usage by that group."

I really like the statement "It wasn't designed so one could write a better alternative to Microsoft Excel or Adobe Photoshop". Longhorn is a platform for all applications, and so the pillars - Avalon, Indigo, and WinFS - must support that large of applications being built on top of it. When we designed XAML we wanted to ensure that any scale of application could leverage the power of the platform with a simple declarative markup...

I also agree with Neil that "The gap is much too large for web developers, which may mean that it may have trouble getting any usage by that group"... this is something we are constantly concerned with. We need a platform that scales from VB to C++, from Web to Win32, from applications to documents... whenever you try to address such breadth it is always a concern that you will miss people. We are really trying to make the platform accessible to web developers, we hope to get feedback on how to do that (without making it impossible to also get the Win32/C++ devs also <G>)...

Matt (no link) comments on my styling post "Why not use CSS, instead of re-inventing it?"...

Avalon originally started with a very CSS-like styling mechanism. I say "CSS-like" because we tried to implement the syntax and rules of CSS, but not the property set. Because we made the decision to base our object model on .NET conventions, the property set for our styles needed to be the same. We didn't want "font-family" in the style, and "FontFamily" in the programing model and markup. It looked something like:

<Window ...>
    <Window.Style>
        Button { Background="Red"; }
    </Window.Style>
</Window>

We got a lot of feedback from internal customers. First, there was the complaint that this syntax wasn't XML. Secondly, there was the complaint that the CSS mechanism for dealing with namespaces was pretty nasty (using pipes). In CSS today most people don't use namespaces, but because of attached properties in Avalon (DockPanel.Dock for example) we would be using these a lot. Third was the lack of support for complex elements. Consider defining a linear gradient in XAML:

<LinearGradientBrush>
    <LinearGradientBrush.GradientStops>
        <GradientStop Offset="0" Color="Red" />
        <GradientStop Offset=".2" Color="Blue" />
        <GradientStop Offset="1" Color="Transparent" />
    </LinearGradientBrush.GradientStops>
</LinearGradientBrush>

That doesn't quite work in the CSS syntax. We where then faced with creating a syntax that wasn't XML, CSS, or anything else people had used - and didn't actually solve all the problems that we needed.

In addition, the CSS model of "rule based" styles (that is, you have a prescedence of rules applied based upon the specificity of them) was a performance nightmare. We knew that we wanted scoped styles, default styles, and massive element composition (50K elements as a goal). Very recently (earlier this year) we did a rearchitecture and part of that was switching from the CSS-like rule based style engine to the simpler explicit XML based style system.

Our goals for the new model where:

• Better performance
• Easier to tool
• Support for complex object definitions
• Unified syntax (no special parser for style)

In addition, there were several features that we could accomplish with our CSS-like approach - namely the notion of "BasedOn" styles. This is a lot like Microsoft Word's model where you can have one style inherit from another style explicitly. In CSS you can kinda make this happen by having two rules have the same sets of rules, but it isn't intuitive and it isn't really possible to provide a good tool experience.

Unfortunately we didn't fully succeed on the unified parser for style and "regular" XAML. From the developer perspective the syntax is the same, but internally we have to create FrameworkElementFactories isntead of inline elements, because the style can be applied multiple times we must provide a model for cloning the trees of elements that are defined within the style.

Which leads us to the other features - VisualTree and VisualTriggers. In Avalon the Style object (which is a CLR object) has several properties, of which VisualTree and VisualTrigger are the two most interesting for this discussion. While CSS has a huge amount of overlap with the property sets that occur in a style, there isn't a part of CSS that works for defining the visual triggers (property sets to occur when a property value or event occurs) and visual tree (the template for the display of that element). Of course, CSS attribute selectors can accomplish some of the work of visual triggers, but they don't support the event based edge triggers that we are planning in the future.

Our goal with XAML (and Avalon) was to provide a simple unified programming model for UI, Documents, and Media. This includes timelines, animation, video, controls, rich text, etc. We felt a unified approach was the only way to produce a simple understandable object model and markup.

Now, for the big pitch...

This is a developer preview. We want your feedback, we are listening to your feedback. The pushback on XUL, CSS, etc, is being listened to. I can't say that we will implement every suggestion that is given, but the entire purpose of this early preview of our technology is to get feedback from the development community. Tell me how to avoid having two languages - CSS for style and XAML for UI, tell me how to make CSS easier to tool, tell me how to make it perform and scale to tens of thousands of elements with nested style sheets... We are listening.

John Montgomery has more fun discussion on XUL...

Obviously not everyone likes what we are doing with XAML... Gerald Bauer says "Evidently working together with others to build a rich internet for everyone wasn't on the agenda."

And he also posted a mini-play:

"Act I: Ellen and Ian discuss Microsoft's Longhorn
Markup Language (XAML):

Ellen:  look at that xaml page. it's just ridiculous
Ian: you mean how much it's like XUL?
Ellen: yeah
        except that they use C# instead of js
        so if you want interactivity, it has to be
compiled
Ian: right.
jeez. wow.
could that be a bigger rip-off?
Ellen: it's stunning"

Obviously I need to look at XUL more - frankly I never have seen the XUL syntax or used it. I found the spec for XUL 1.0 over at Mozilla and saw some of the markup there...

How do I create a new custom binary behavior using XUL? I understand that in IE I am able to implement IElementBehavior and then I can create a new custom element, but I'm wondering how this works in XUL?

XAML is a simple langauge that binds to CLR objects - there is no set of "intrinsic" objects in XAML, everything is based on CLR metadata for types.

Anyway, obviously everyone will have their different views, should be a fun couple years while we all try to make progress on this stuff...

A great comment from Yves says "Have you not learned anything from CSS, HTML and the future direction of not using inline styles, but using CSS for look and feel(color, font, position ...) outside of the HTML document (or at least in the head)?"...

Avalon has a solid notion of styles. All appearance of an element can be determined from a style. Avalon styles are hierarchical - that is they can be defined at any scope an impacts from that location down in the tree. Avalon styles are not rule based (like CSS) but rather used a "named style" mechanism. Avalon styles support the definition of property and event based transformations (although I believe the event triggers aren't working in the PDC bits). First, lets look at a basic style:

<Window ...>
    <Window.Resources>
        <Style def:Name="MyStyle"><Button Background="Red" /></Style>
    </Window.Resources>
    <Button>Hello</Button>
</Window>

In this example the button *would not* be colored red. The style has a name, and therefore you would need to specify on the button:

<Button Style="{MyStyle}">Hello</Button>

The curly brace syntax means that the style is being set from a resource reference. Resources can be defined and overriden anywhere in the tree. If you have browsed the SDK documentation for Longhorn you have probably seen styles that look like this:

        <Style><Button Background="Red" /></Style>

This is what we call a "default" or "implicit" style. This requires some explanation. You see every element has a default value for every property. The default value for the "Style" property is the type of that element... OK, more explanation needed. The name of a resource can be any object, not just a string. Thus, you can actually make a resource have the name of "*Int(5)" which would be the integer value of 5 (don't try this in the PDC build, doesn't work <G>). However, one thing you can do is use a type reference:

        <Style def:Name="*typeof(Button)"><Button Background="Red" /></Style>

Ahh! So, we can use the type of an element to be the key for that style in the resource collection.

When designing the styling system we had a lot of discussion about how people would discover the default value of the style. We could have used a naming convention like "SysButton" or something else, but in the end the simplicity of using the type object from the CLR was the perfect fit. The final piece of this puzzle is that when you omit the name of style, we assume that you meant to use the type of the element that the style is for. Bingo.

OK, now that we have named the style, and have a way for elements to hook up to the style, how does a style work?

The basis of style is an "as use" syntax, that is - the content of the style should be just like the element when you would use it. This made it easy for cut and paste type operations, but also made a single syntax for people to learn. In addition, there are style specific properties you can set - like "VisualTree" and "VisualTriggers".

Before I dive into the fun of tree & triggers - one more comment about the lookup rules for resources (and therefore styles)... You can define resources at any level of the hierarchy. Including the application object. Thus, if you want to define the look for all buttons in your application you can simply say:

<Application ...>
    <Application.Resources>
        <Style def:Name="MyStyle"><Button Background="Red" /></Style>
    </Application.Resources>
</Application>

Although this is a really long winded response to Yves, I hope he can see that we haven't forgotten styling.

In comments on my brief history of XAML post there seems to be a lot of "Why don't you make XAML be pure data?"...

Purity

I used to work on the .NET Framework team, including Windows Forms and ASP.NET. There was never a debate about ASP.NET supporting inline script, it was required because they wanted to preserve the experience for ASP developers. When it came to imlementing the VS designer we all came to a reluctant decision that the "pure" way of writing ASP.NET application should be with a separate code behind file. There werre some technical reasons (we didn't have intellisense in the inline case) and there were some architectural purity arguments (shouldn't mix code and UI definition). So we shipped.

The feedback from the community has been rather vocal about this decision. There are so many times when dropping little snippets of code into the UI definition is amazingly fast and easy. In Web Matrix they made the inline code be the default.

When we started on XAML we had this same debate, and we basically decided early to side with our past experience with ASP.NET. While the architecturally pure view was to complete separate code and UI definition, the reality was that developers like to do things that aren't architecturally pure ;-)

IDs & Events

In addition to the purity argument, there is the ID and event problem. When defining some UI in XAML you often do something like this:

<Window ...>
    <TextBox ID="text1" /><Button Click="DoSomething">Click</Button>
</Window>

Then, in the code behind file you want to be able to simply say:

Sub DoSomething(sender As Object, e as ClickEventArgs)
    text1.Text = "Something"
End Sub

To accomplish this, you need to have a shared namespace (from the conceptual standpoint, not a shared CLR or XML namespace) between the code and the markup. Given that in this case the markup is defining a field in the class that will be generated you quickly want to be able to also specify the modifiers:

<!-- We don't support this yet!! -->
<TextBox ID="text1" def:Modifiers="public" />

This isn't in the builds yet, but you can see how quickly the worlds of the UI definition and the code behind begin to blur.

Commands and DataBinding to the rescue

We believe that because of the RAD aspects and the ID/Event issues that XAML should support some of these code features - however there are clearly some people that would like to have this not be the cause. Of course, you can choose not to use these features, but in addition we are working on adding features to make this separation be easier.

Commands are the ability for a component or application define a logical command that can be handled within the display tree. This means that you can create the definition of "Cut", "Copy", "Save", "PostToBlog", whatever you want (many of these are common commands that are built in). These logical commands can then be used to have a loose coupling between your logic in the code behind and the element tree defined in markup.

DataBinding is another key part. With data binding you can bind any property of any element to any property of any other object. Thus you can actually have a complete contract between your code behind and your markup implemented through a set of business objects.

While I haven't been involved in every aspect of the design and history of XAML, I thought you all might enjoy a bit of the history of how we got to where we are with XAML...

An early debate on the Avalon team was about what our markup should look like. We knew that we wanted a declarative UI model - it is actually something we have had for a long time. The Avalon team was formed with members from all over the company - User, IE, etc. And each team had a different history with markup. Obviously the IE folks had used HTML and VML in the past, while the User folks had used RC files. To add to the great debate there was also the new success of ASP.NET and their form of markup.

After great debate, we decided that the programatic object model would be based on .NET conventions. We also felt that the markup should have the same programming model as code. Neither HTML nor RC files had this "markup == object model" tenet, and it made programming difficult. ASP.NET had (basically) this model, and people seemed to really like that.

Finally we decided that the markup should be a new format that was, in fact, a persistence format for .NET objects. Thus, code like this:

Button b = new Button();
b.Text = "Hello";
b.Background = Colors.Red;

Would be transformed into:

<Button Text="Hello" Background="Red" />

Of course, that wasn't the end of the debates. Now of course, we had to decide on the object model for our objects. Should we try to make the object model familiar to Win32, HTML, WinForms, ASP.NET, or some other group of developers? There were various camps, but after the success of .NET in 2001/2 it became increasingly obvious that a WinForms/ASP.NET based object model would be the right thing for majority of developers.

Anyway, back to the markup...

The general rules for XAML go something like this:

1. Tag names are class names. The CLR namespace and assembly is discovered by an XML namespace mapping scheme (more later).
2. XML Elements are mapped to CLR properties or events
3. Sub-elements of a tag can either be other class instances or "compound" properties (of the form Type.PropertyName)

There are a few more advanced rules around the "Definition" namespace and Style.VisualTree, but basically these three rules are it. Property values are converted from strings in markup to code using TypeDescriptors (just like in ASP.NET). Rule #3 has some complications to it - there are several ways that a child object gets attached to a parent (IAddChild, IList, etc.).

There is a fourth rule:

4. The root tag of a markup file is the base type of the class the markup file defines.

Thus a file like this:

<Window xmlns="..." xmlns:def="..." def:Class="Window1">
    <Button>Hello</Button>
</Window>

Would define a new type called "Window1" that derives from "Window".

Here introduces one of our current debates - is XAML a programming language or a resource format? With XAML you can define new types, define interactivity with "def:Code", and specifiy member variables of the type using "ID". XAML also defines the UI appearance of something, and is used for localization scenarios. XAML lacks any imperitive constructs (branching, etc.). XAML is more of a "programming model" rather than a language, so we have left it at that - "XAML is a declarative programming model".

In the PDC bits their are two modes of XAML compilation - binary (BAML) and code (CAML). We are still working on analyising the two options - CAML works just like ASP.NET, it converts XAML into code (VB.NET, C#, C++, any other CodeDOM language)... BAML uses a binary format and also creates a small section of code for the parts of XAML that can't be represented in binary (like the outer class definition). CAML is the default in PDC bits, and you can use Optimization="Download" in the project file for getting BAML.

This entry is turning into a bit of a rambling mess... more later...