Longhorn时代，浏览器的终结？——关于Avalon和XAML
很久以前的一篇文章，当初应该是《程序员》的稿子，有没有发表我就已经忘记了，今年在整理的过程中突然找到了，也不知道里面的观点是否正确，仅仅当着一个过去的思考，关于Longhorn的介绍，请参考《MSDN开发精选》第一期的特别策划
Longhorn时代，浏览器的终结？
——关于Avalon和XAML
写完那场浏览器大战，我内心始终无法平静，也许是还没有从场戏的情景走出来，相反于人类的和平，在技术“和平”的年代，的确有点苦闷，在这个高速发展的年代，我们居然被IE统治2年多的时间（确切的说应该是IE5出来以后就算，所以说应该算接近5年），我们需要一些新鲜的事物来刺激我们渐渐麻木的神经。
第一次听到Longhorn的时候有点稀里糊涂的，根本不知道这个叫着“长角”的家伙有何特异功能，值得那个帝国托付全部的家当，号称有三大创新技术的Longhorn,居然那些技术也有一些稀奇古怪的代号：Avalon,Indigo,WinFS，不知道这玩意儿是不是将来的 Window .Net Server 2005 or/2006。我们是不用去指望了，也许发布的他日真的会使用我预言的系统名称，也许又是一个代号，只是希望代号能够好听一点，能够好读一点，等到看到XAML的时候，我终于被这些代号折腾的不行了，本来应该发音“zammel”终于被我读成了“折磨”。
好了，言归正传，代号为“Longhorn”的下一版 Microsoft® Windows® 操作系统都是一个重要的里程碑。“Longhorn”是第一个用托管代码构建的操作系统，而且首次采用了最新的存储子系统（代号为“WinFS”），这种存储系统是文件系统概念的一次革命。它还是第一个支持自然搜索技术 (Natural UI) 的操作系统，这种技术自动解决了查询文本固有的大量多义性问题。Longhorn包含3大革命性的技术，第一是代号为"Avalon"的图形和展示引擎，第二是代号为"Indigo"的新的通信架构，第三是代号为"WinFS"的新的文件系统。而代号为Avalon的图形展示引擎则是基于XML来展示的，而基于Longhorn的应用程序除了传统的VB.Net,C#可以编写之外，同时引入了一个新的XAML的语言。
什么是Avalon
Avalon是下一版本的Windows（代号“Longhorn”）的一部分，主要由新加到.NET 框架中的一组类集合而成。目前，用于Avalon编程的最重要的新命名空间有多个名称，例如，MSAvalon.Windows、MSAvalon.Windows.Controls和MSAvalon.Windows.Media（在 Longhorn 最终发布之前，这些名称将进行更改）。有了Avalon，您就可以利用C#、Visual Basic® .NET 或者任何其他支持.NET 公共语言规范 (CLS)的语言编写应用程序。这些程序与目前可编写的Windows窗体应用程序颇为相似。即，Avalon 的标准部分。
什么是XAML
Avalon会定义一个可在Longhorn中使用的新标记语言，其代号为“XAML”（可扩展应用程序标记语言）。可以使用XAML来定义文本、图像和控件的布局，这与使用HTML非常相似。大多数写入Avalon的应用程序均可能同时包含程序代码和XAML。您将使用XAML定义应用程序初始的可视界面，并编写用于实现其他功能的代码。您可以将程序代码直接嵌入到XAML中，也可以将它保留在一个单独的文件内。能够用XAML实现的所有功能均可以通过程序代码实现。因此，根本无需使用任何XAML也有可能编写程序。但是，反之则不行；许多任务只能通过程序代码完成，因此，只有最简单的应用程序才会只包括XAML。
利用 XAML 元素，您可以控制每个页的布局，包括文本和图像的显示、插入按钮、文本框等交互式组件。总之，XAML 是用于以声明方式呈现构成应用程序的页的用户界面的语言。当然，除了使用 XAML，您也可以完全使用过程代码来编写 Longhorn 的应用程序。一般来说，一个基于 Longhorn 的成功的应用程序会同时具备 XAML 页和托管过程代码。您可以按自己的方式来组合它们，但这两者的任何组合都是可以接受的。
Avalon和XAML如何工作？
我们首先来看一个XAML的代码，也就是最经典的“Hello World”程序。将如下的代码存储成HelloWorld.xaml就可以。
<TextPanel xmlns="http://schemas.microsoft.com/2003/xaml"
Background="BlanchedAlmond"
FontFamily="Comic sans MS"
FontSize="36pt"
HorizontalAlignment="Center">
Hello, world!
</TextPanel>
由于其中没有代码，因此您可以将 HelloWorld.xaml 文件直接加载到 Microsoft Internet Explorer 的 Longhorn 版本中，然后您将看到类似于一个 Web 页的内容。还可以使用一个目前称作 MSBuild 的程序来编译 HelloWorld.xaml。进行这种编译时，还需要两个其他的短文件（此处未显示）。其中一个扩展名为 PROJ 或 MSPROJ 的文件会提供有关该程序的一些信息并列出所有必需的源文件（XAML 以及其他文件）。还需要另外一个 XAML 短文件来指出执行该程序时首先显示哪个 XAML 页。运行 Hello World 的可执行文件，您将看到一个类似于 Windows 程序的内容。图 1 同时显示了这两个版本。
图 1 Hello World 作为页面和作为程序
从某种意义上面来说,XAML和HTML页面非常相似，不过因为是基于XML的，所以拥有了比较严格的规范，同时因为在Avalon下执行，Longhorn整个操作系统成为其容器，相对于IE而言，拥有更加广阔的空间。
1) 布局选项
可以采用Windows传统的点阵布局，同时支持HTML风格的流式布局。FlowPanel,DockPanel,TextPanel等等各个元素能够满足你开发过程中的大部分要求。
2) 事件处理
基于 Windows 的应用程序不仅仅是为了显示 Web 页，它们需要以非常专门的方式响应用户界面事件。这种情况下，必须由实际的编程代码对 XAML 进行补充。您可以将这种代码放到单独的文件中，也可以将其直接嵌入到 XAML 中。
3) 元素和对象
如果页面上面有多个元素，你可以采用和HTML类似的模型来处理.DHTML通过window.event.srcElement这样的方式来标识多个事件源，同一个处理逻辑，在XAML也可以同样的实现。
XAML vs HTML，浏览器消失了？
去做这样的比较有点没有意思，因为这根本不是一个层次和概念上的比较，不过熟悉Web编程的朋友们应该也会发现，这个和HTML页面是如此惊人的相似，开始的时候我甚至以为没有太多的区别，只是微软招摇撞骗的幌子罢了。
这次，我的确错了，而且错的离谱，至于原因如何，我会在后面的文字去做深刻的检讨，首先来看看误导我的理由吧。
1． 默认的HTML布局是Flow Layout的，不过CSS的后续支持能够让大部分的HTML元素设置style=”left:50px;top:30px;”这样的属性。
2． 事件处理比较经典的写法是<button onclick=”showMsg()” value=”ClickMe”>这样的写法。
3． 元素和对象可以通过DOM(Document Object Model)来访问，对于相当一部分的HTML元素，是可以支持时间冒泡的，至于事件源，在DHTML开发中通过window.event.srcElement.这样的属性可以轻易的获取，而需要拦截一些事件的冒泡通过window.event.cancelBubble=true就能够取消源事件往上级容器传递。
我以为这就是所谓的XAML，终于知道不是微软在哗众取宠，而是我太无知，那个Indigo，才让我明白所谓Avalon和所谓XAML不是想象的如此简单。Longhorn的应用模型是“一次编写，n次部署”，Avalon作为图形展示引擎负责XML格式的XAML文件的图形绘制，而真正底层工作的核心在于Indigo. Indigo 的一个主要优点是，它会为所有基于公共语言运行库 (CLR) 的远程技术提供一个统一的编程模型和协议栈。Indigo 会将 .NET Remoting、ASMX、System.Messaging 和 .NET Enterprise Services 的最佳功能结合到一个框架中，使得开发人员能够自由组合各种功能，如声明性事务处理、可插接式侦听器和传输以及基于 XML 架构的序列化。一个应用程序的无缝部署是通过Indigo来完成的，因此那些XAML的代码逻辑也是Indigo统一管理的，这个就是和HTML本身最大的区别，在传统的浏览器上面，不管多复杂的脚本代码，大部分都是为了UI显示而考虑的，任何系统级别的消息通信在浏览器这个容器都是受限的。
说到这里，我们不得不提出另外一个问题，是桌面消失了还是浏览器消失了？在这个时候我首先认同的是可以考虑桌面的消失，因为所有的代码都可以通过Longhorn版本的浏览器下载然后编译执行，那么既然所有的应用都可以在浏览器运行，是不是考虑让桌面应用退出历史舞台了，正当我为自己天才的结论沾沾自喜的时候，突然发现连浏览器也一起消失了，是的，浏览器的概念也已经模糊了…….
从某种意义上来说，我们已经没有桌面应用和浏览器应用的概念，通过编写XAML，我可以可以任意的部署实现，这个时候，整个Longhorn就是一个本质意义上的浏览器容器，通信和调度通过Indigo来完成，而Avalon则用来完成UI的组织。
革命之后的思考
从浏览器IE5的颠峰到IE6的雄霸天下，在整整一个时期之内我们都是在那样的思想之下去考虑问题，包括应用及其体系结构本身，我们拥有曾出不穷的产品可以选择，但是不管如何应用始终摆脱不了C/S，B/S这两大主流应用程序架构，虽然有很多的Articheture和Pattern可以指导和补充我们现有的应用。不过依然无法摆脱两个架构的局限性，于是Thin Client还是Rich Client永远是各大社区讨论的热点所在，一个可以看到改变的是.Net的所谓Smart Client的出现，Macromedia的Flash技术也是一个从Rich Client àThin ClientàSmart Client演化过程中一个非常优秀的解决方案。
而那个Avalon和XAML的设计思想有点超出我能够理解的范围，那样基于标记定义的语言，那样的图形引擎，会不会改变我们现有的思想，浏览器消失了还是永存？看今天的Longhorn，看看“折磨”，不知道你是否能够得到另外的答案。
写在后面：
说实话，写这样的文章让我战战兢兢，总害怕在亵渎什么，对于XAML，沸沸扬扬之后“尘归尘，土归土”，我喜欢看到新技术的演变，虽然有些的改变让我们有点无法接受，不过依然相信这种变革能够提高生产力，从信息技术发展的历程来看，旧有的技术总是会被新技术取代的，而浏览器，注定要被取代，至于是否我们今天提到的一些技术（所谓大统一的浏览器），那么就需要时间去验证了
Eric Liu
2004年5月19日凌晨5点于京城
很久以前的一篇文章，当初应该是《程序员》的稿子，有没有发表我就已经忘记了，今年在整理的过程中突然找到了，也不知道里面的观点是否正确，仅仅当着一个过去的思考，关于Longhorn的介绍，请参考《MSDN开发精选》第一期的特别策划
Longhorn时代，浏览器的终结？
——关于Avalon和XAML
写完那场浏览器大战，我内心始终无法平静，也许是还没有从场戏的情景走出来，相反于人类的和平，在技术“和平”的年代，的确有点苦闷，在这个高速发展的年代，我们居然被IE统治2年多的时间（确切的说应该是IE5出来以后就算，所以说应该算接近5年），我们需要一些新鲜的事物来刺激我们渐渐麻木的神经。
第一次听到Longhorn的时候有点稀里糊涂的，根本不知道这个叫着“长角”的家伙有何特异功能，值得那个帝国托付全部的家当，号称有三大创新技术的Longhorn,居然那些技术也有一些稀奇古怪的代号：Avalon,Indigo,WinFS，不知道这玩意儿是不是将来的 Window .Net Server 2005 or/2006。我们是不用去指望了，也许发布的他日真的会使用我预言的系统名称，也许又是一个代号，只是希望代号能够好听一点，能够好读一点，等到看到XAML的时候，我终于被这些代号折腾的不行了，本来应该发音“zammel”终于被我读成了“折磨”。
好了，言归正传，代号为“Longhorn”的下一版 Microsoft® Windows® 操作系统都是一个重要的里程碑。“Longhorn”是第一个用托管代码构建的操作系统，而且首次采用了最新的存储子系统（代号为“WinFS”），这种存储系统是文件系统概念的一次革命。它还是第一个支持自然搜索技术 (Natural UI) 的操作系统，这种技术自动解决了查询文本固有的大量多义性问题。Longhorn包含3大革命性的技术，第一是代号为"Avalon"的图形和展示引擎，第二是代号为"Indigo"的新的通信架构，第三是代号为"WinFS"的新的文件系统。而代号为Avalon的图形展示引擎则是基于XML来展示的，而基于Longhorn的应用程序除了传统的VB.Net,C#可以编写之外，同时引入了一个新的XAML的语言。
什么是Avalon
Avalon是下一版本的Windows（代号“Longhorn”）的一部分，主要由新加到.NET 框架中的一组类集合而成。目前，用于Avalon编程的最重要的新命名空间有多个名称，例如，MSAvalon.Windows、MSAvalon.Windows.Controls和MSAvalon.Windows.Media（在 Longhorn 最终发布之前，这些名称将进行更改）。有了Avalon，您就可以利用C#、Visual Basic® .NET 或者任何其他支持.NET 公共语言规范 (CLS)的语言编写应用程序。这些程序与目前可编写的Windows窗体应用程序颇为相似。即，Avalon 的标准部分。
什么是XAML
Avalon会定义一个可在Longhorn中使用的新标记语言，其代号为“XAML”（可扩展应用程序标记语言）。可以使用XAML来定义文本、图像和控件的布局，这与使用HTML非常相似。大多数写入Avalon的应用程序均可能同时包含程序代码和XAML。您将使用XAML定义应用程序初始的可视界面，并编写用于实现其他功能的代码。您可以将程序代码直接嵌入到XAML中，也可以将它保留在一个单独的文件内。能够用XAML实现的所有功能均可以通过程序代码实现。因此，根本无需使用任何XAML也有可能编写程序。但是，反之则不行；许多任务只能通过程序代码完成，因此，只有最简单的应用程序才会只包括XAML。
利用 XAML 元素，您可以控制每个页的布局，包括文本和图像的显示、插入按钮、文本框等交互式组件。总之，XAML 是用于以声明方式呈现构成应用程序的页的用户界面的语言。当然，除了使用 XAML，您也可以完全使用过程代码来编写 Longhorn 的应用程序。一般来说，一个基于 Longhorn 的成功的应用程序会同时具备 XAML 页和托管过程代码。您可以按自己的方式来组合它们，但这两者的任何组合都是可以接受的。
Avalon和XAML如何工作？
我们首先来看一个XAML的代码，也就是最经典的“Hello World”程序。将如下的代码存储成HelloWorld.xaml就可以。
<TextPanel xmlns="http://schemas.microsoft.com/2003/xaml"
Background="BlanchedAlmond"
FontFamily="Comic sans MS"
FontSize="36pt"
HorizontalAlignment="Center">
Hello, world!
</TextPanel>
由于其中没有代码，因此您可以将 HelloWorld.xaml 文件直接加载到 Microsoft Internet Explorer 的 Longhorn 版本中，然后您将看到类似于一个 Web 页的内容。还可以使用一个目前称作 MSBuild 的程序来编译 HelloWorld.xaml。进行这种编译时，还需要两个其他的短文件（此处未显示）。其中一个扩展名为 PROJ 或 MSPROJ 的文件会提供有关该程序的一些信息并列出所有必需的源文件（XAML 以及其他文件）。还需要另外一个 XAML 短文件来指出执行该程序时首先显示哪个 XAML 页。运行 Hello World 的可执行文件，您将看到一个类似于 Windows 程序的内容。图 1 同时显示了这两个版本。
图 1 Hello World 作为页面和作为程序
从某种意义上面来说,XAML和HTML页面非常相似，不过因为是基于XML的，所以拥有了比较严格的规范，同时因为在Avalon下执行，Longhorn整个操作系统成为其容器，相对于IE而言，拥有更加广阔的空间。
1) 布局选项
可以采用Windows传统的点阵布局，同时支持HTML风格的流式布局。FlowPanel,DockPanel,TextPanel等等各个元素能够满足你开发过程中的大部分要求。
2) 事件处理
基于 Windows 的应用程序不仅仅是为了显示 Web 页，它们需要以非常专门的方式响应用户界面事件。这种情况下，必须由实际的编程代码对 XAML 进行补充。您可以将这种代码放到单独的文件中，也可以将其直接嵌入到 XAML 中。
3) 元素和对象
如果页面上面有多个元素，你可以采用和HTML类似的模型来处理.DHTML通过window.event.srcElement这样的方式来标识多个事件源，同一个处理逻辑，在XAML也可以同样的实现。
XAML vs HTML，浏览器消失了？
去做这样的比较有点没有意思，因为这根本不是一个层次和概念上的比较，不过熟悉Web编程的朋友们应该也会发现，这个和HTML页面是如此惊人的相似，开始的时候我甚至以为没有太多的区别，只是微软招摇撞骗的幌子罢了。
这次，我的确错了，而且错的离谱，至于原因如何，我会在后面的文字去做深刻的检讨，首先来看看误导我的理由吧。
1． 默认的HTML布局是Flow Layout的，不过CSS的后续支持能够让大部分的HTML元素设置style=”left:50px;top:30px;”这样的属性。
2． 事件处理比较经典的写法是<button onclick=”showMsg()” value=”ClickMe”>这样的写法。
3． 元素和对象可以通过DOM(Document Object Model)来访问，对于相当一部分的HTML元素，是可以支持时间冒泡的，至于事件源，在DHTML开发中通过window.event.srcElement.这样的属性可以轻易的获取，而需要拦截一些事件的冒泡通过window.event.cancelBubble=true就能够取消源事件往上级容器传递。
我以为这就是所谓的XAML，终于知道不是微软在哗众取宠，而是我太无知，那个Indigo，才让我明白所谓Avalon和所谓XAML不是想象的如此简单。Longhorn的应用模型是“一次编写，n次部署”，Avalon作为图形展示引擎负责XML格式的XAML文件的图形绘制，而真正底层工作的核心在于Indigo. Indigo 的一个主要优点是，它会为所有基于公共语言运行库 (CLR) 的远程技术提供一个统一的编程模型和协议栈。Indigo 会将 .NET Remoting、ASMX、System.Messaging 和 .NET Enterprise Services 的最佳功能结合到一个框架中，使得开发人员能够自由组合各种功能，如声明性事务处理、可插接式侦听器和传输以及基于 XML 架构的序列化。一个应用程序的无缝部署是通过Indigo来完成的，因此那些XAML的代码逻辑也是Indigo统一管理的，这个就是和HTML本身最大的区别，在传统的浏览器上面，不管多复杂的脚本代码，大部分都是为了UI显示而考虑的，任何系统级别的消息通信在浏览器这个容器都是受限的。
说到这里，我们不得不提出另外一个问题，是桌面消失了还是浏览器消失了？在这个时候我首先认同的是可以考虑桌面的消失，因为所有的代码都可以通过Longhorn版本的浏览器下载然后编译执行，那么既然所有的应用都可以在浏览器运行，是不是考虑让桌面应用退出历史舞台了，正当我为自己天才的结论沾沾自喜的时候，突然发现连浏览器也一起消失了，是的，浏览器的概念也已经模糊了…….
从某种意义上来说，我们已经没有桌面应用和浏览器应用的概念，通过编写XAML，我可以可以任意的部署实现，这个时候，整个Longhorn就是一个本质意义上的浏览器容器，通信和调度通过Indigo来完成，而Avalon则用来完成UI的组织。
革命之后的思考
从浏览器IE5的颠峰到IE6的雄霸天下，在整整一个时期之内我们都是在那样的思想之下去考虑问题，包括应用及其体系结构本身，我们拥有曾出不穷的产品可以选择，但是不管如何应用始终摆脱不了C/S，B/S这两大主流应用程序架构，虽然有很多的Articheture和Pattern可以指导和补充我们现有的应用。不过依然无法摆脱两个架构的局限性，于是Thin Client还是Rich Client永远是各大社区讨论的热点所在，一个可以看到改变的是.Net的所谓Smart Client的出现，Macromedia的Flash技术也是一个从Rich Client àThin ClientàSmart Client演化过程中一个非常优秀的解决方案。
而那个Avalon和XAML的设计思想有点超出我能够理解的范围，那样基于标记定义的语言，那样的图形引擎，会不会改变我们现有的思想，浏览器消失了还是永存？看今天的Longhorn，看看“折磨”，不知道你是否能够得到另外的答案。
写在后面：
说实话，写这样的文章让我战战兢兢，总害怕在亵渎什么，对于XAML，沸沸扬扬之后“尘归尘，土归土”，我喜欢看到新技术的演变，虽然有些的改变让我们有点无法接受，不过依然相信这种变革能够提高生产力，从信息技术发展的历程来看，旧有的技术总是会被新技术取代的，而浏览器，注定要被取代，至于是否我们今天提到的一些技术（所谓大统一的浏览器），那么就需要时间去验证了
Eric Liu
2004年5月19日凌晨5点于京城
回复Comments
作者:
{commentrecontent}