几天前没事，重温了一下以前喜欢的FLASH。又在网上看到了Micromedia的三大新战略的新闻。Micromedia已经开始表明他们战略意图的转向，想在移动通讯、网上教学甚至服务器软件等领域占有一席之地，对于Micromedia的Breeza、FLex、ColdFusion我还只是闻其声未见其人，不过在使用了FLASH MX 2004后，我不由得想提出几个问题。
FLASH可以做些什么？
我们还需要ASP.net吗？
我们还需要IE吗？
FLASH可以做些什么？打开FLASH MX 2004，马上可以看到一些令人熟悉的组件：DataSet、DataGrid、DataField，还有XMLConnector、WebServiceConnector等。这些组件可以让我们快速的建立一个界面，向用户显示信息。既然如此，我们的WEB站点是否可以重新规划，用一种新的方式来展现内容？
建立一个FLASH，运行它，然后向服务器发送一道XML格式的指令，如下
<?xml version="1.0"?>
<request>
<命令>执行查询</命令>
<查询类型>选择查询</查询类型>
<查询数据表列表>
<数据表>user</数据表>
<数据表>article</数据表>
</查询数据表列表>
<查询数据表联结关系>on user.id = article.userid</查询数据表联结关系>
<查询字段列表>
<字段名>username</字段名>
<字段名>title</字段名>
<字段名>content</字段名>
<字段名>dateandtime</字段名>
<字段名>other</字段名>
</查询字段列表>
<条件>article.id=1</条件>
<分页>2</分页>
<排序字段>dateandtime desc</排序字段>
</request>
服务器接收这道指令，于是运行一个查询，返回一个XML数据页，FLASH收到数据，在客户端显示出来。
这是不是有点麻烦？不，如果我们把这种向服务器发送指令的方式封装成一个FLASH组件，让FLASH制作者可以轻易的把一些操作转换成发送到服务器的指令，那就显得并不困难。
服务器做些什么？服务器只需要执行查询，或者执行一些功能命令，向网络输出二进制流，或者返回一些信息就行了。如果服务器端和FLASH之间的交互是规范的，有一定模式的，那么，服务器的组件就可以固定下来，可以重用，可以共享。
这有什么不同吗？当然不同，我们可以简单的把WEB网站看做三层，对数据库的操作层、执行一些功能的应用层、格式化页面的表现层。那么，现在服务器只需要完成对数据库的操作和一些基本的功能就行了，而表现形式，完全可以放在FLASH中完成。如果这显得麻烦，我们就可以利用FLASH可以扩充的组件，制作许多个容易使用的组件。让代码可以重用，一切就会变得简单许多。还觉得麻烦的话，我们可以让服务器在输出前，把一些内容用XSL转换一下，再把HTML内容放在一个XML元素里传过来。FLASH就可以用一个文本框的HtmlText属性来展示。
OK，我们可以做到这些，这并不困难，问题是，如果我们这样做，那么
我们还需要Asp.net这个庞然大物做什么？
在这里提出这样一个问题可能很可笑，连我自己也不敢大声的说出这句话。可是，让我们想象一下，如果我们真的象上述那样用FLASH来建立网站的话。我们需要一个什么样的服务器？
一个更小巧的服务器，不需要对不规范的脚本进行解释，只需要执行一些功能就行了，然后就可以让客户端的FLASH调用，并返回规范化的数据。
一个更快速的服务器，既然象上面说的那样，做出的Asp.net组件可以重用，可以固化，那么为什么不直接固化到服务器程序里，这样会更加快捷。
一个更加安全的服务器，我们可以更好的控制服务器，不需要再让一个空间使用者在服务器上写一些谁也无法预料的程序。
一个可以描述规范的服务器，服务器接收到FLASH的命令后，如何输出，应该以什么样的格式进行输出？我们可以提供一些描述性指令，允许用户建立一些象MS SQL中的存储查询一样的功能，供用户的需要进行调用。
当然，你可以说我们为什么需要FLASH？ASP.net的模板可以做得更好。可是ASP.net可以象FLASH那样把动与静完美的结合吗？Asp.net可以把数据输出后还能有效的、实时的控制数据的动态效果吗？FLASH已经深入人心，SVG和VML还却在那里吵架。或许FLASH制作有些麻烦，但是那些闪客已经从FLASH最初的版本中闪出了活力，谁能说他们不会做得更好？
我并不想在这里争论FLASH网站是否可以普及（建立FLASH全站完全可能），我只想提出一个猜想，事实上，在Micromedia的新战略中，已经可以觉察到这些意图，问题只是，这会带来什么。
这会带来什么？是的，一旦服务器端的指令可以变得规范化、固化、简单化，那么，我们的ASP.net和ASP程序员将不再需要站在服务器端写一些代码，向客户端发送数据，并且在发送之后就象往大海里扔了一个瓶子，谁也不知道它会变成什么样。
于是，未来便属于FLASH组件编程员了，他们向服务器发送指令，要求得到数据。然后处理这些数据，用生动的、动态的形式展现出来。我们不再是站在服务器上思考，我们就是客户，WEB站点不再是一堆用链接线串起来的单个的页面，它将象一个windows应用程序一样，成为一个整体。最多，我们再用loadmovie从服务器上读取几个子程序罢了（SWF文件）。而所有的文字内容、图片、声音、媒体都可以被当成单纯的数据被取用。
OK，那么就有了下一个问题，
我们还需要IE吗？
新的FLASH将给我们带来什么？想象这样一段QQ对话。
短歌行：长哥，我喜欢《老康蓝屋》这个网站，哪有啊？
长恨歌：你有《中国网站大全》这个网站的FLASH吧，打开它，在里面搜索一下就有了，很有名的，马上可以下载。
短歌行：哦，谢谢了，另外，《清纯美少女》这个网站怎么运行不了了？
长恨歌：那个网站有点色，以前的服务器被封了，你到BT上下载一个最新版本的，可以控制服务器IP地址，我可以把最新的服务器IP告诉你。
短歌行：哇，太棒了，我就去下载。
有意思，这将是一种什么样的网站？一个FLASH就是一个网站的入口，它究竟是一个应用程序，还是一个首页？我们还需要域名吗？我们的FLASH为什么一定要告诉别人，我们是从 www.csdn.net这样的地方取数据的呢？为什么不直接向61.186.252.133取数据呢，反正用户只要记住CSDN.swf这个顶顶大名的网站就行了。我们可以在网上分发这个FLASH，BT下载、FlashGET下载，让用户以任何形式得到。我们可以控制FLASH读取数据的位置，一个服务器出现故障了，让客户端的FLASH去别的地方取数据就行了，用不着发布什么“请用户原谅，我们的服务器一部分出现故障，暂时停机，请访问下列地址”之类的公告。
呵呵，想得太远了，万维网可不是那么容易被打破的，但是方法变了，网络的模式也将出现变化。如果拥有了FLASH网站，我们一定要把FLASH死死的放在一个IE里进行播放吗？
当然，还有一个问题，假如我想在浏览 "老康蓝屋.swf"时去看"清纯美少女.swf"，我是不是应该关掉《老康蓝屋》，再打开《清纯美少女》？那太麻烦了，难道我们不能象在IE中点击一个链接一样访问另一个网站？
可以，我们做一个FLASH播放器就行了，把网站FLASH放到这个播放器中播放，并接收指令，在链接时跳转到另一个网站FLASH就OK。但是，只要这个播放器是我们自己做的，就难以普及、难以规范化、难以形成标准。
或许Breeza可以做到，但我没用过Breeza，所以也不知道它究竟会是什么样。我只是想设想一下，我们需要的这样一个播放器，它应该做些什么。
，FLASH中的一个链接应该提供一些什么信息？网站名、网站FLASH的最优先的索取位置，这将是一个IP或者是一个网址，或者它将是一个巨型服务器数据库中的索引ID值，我们还可以要求一个FLASH网站提供一个类似COM组件那样的唯一标识。这样的话我们的FLASH播放器就可以根据这些信息找到我们需要的网站FLASH。
为什么需要唯一标识？假设我们在最优索取位置的地点找不到这个网站FLASH，那么，我们可以向互联网公布一种类似BT一样的查询公告，看看哪个上网的用户的电脑上有，如果允许的话，收过来，让我们共享。而我们的这个FLASH的播放器就负责发布公告，也可以收听公告，网上的一些服务器负责验证标识。还有一点，一旦有了这样一个标识，那么，负责分发标识的机构必然会大受瞩目，这个机构收费吗？这个机构是不是只对那些有名的网站FLASH分发标识，并收取费用？呵呵，想得太远了。
说到这里，许多朋友肯定会认为我的想象力太丰富了，但不切实际，Asp.net是艘航空母舰，IE是个老熟人，哪有想扔就扔的。
我承认，它们都有许多数不清的优点，我也不认为一下子就会抛弃它们，但是，为什么我们要因此而制止想象力，为什么我们不能去想象一种新的互联网模式，中国的程序员写了多少年代码，始终在别人写的规范里、画的圈子里转悠。为什么我们不能大胆一些，抢占一些新的东西，建立一套我们的规范、我们的标准。让我们说出的每一句话都成为他人的标准？
OK，我们想这样，那么我们要做些什么？
如同前面所说，这样的网站FLASH需要一个由服务器端提供的功能模块，需要一些优秀的FLASH组件，我们可以建造它、公布它、共享它、甚至开放源代码，让许多人使用它，盗版它。只要这些东西足够的优秀，可扩充，面向长远的未来，使用的人足够多，我们就可以确立一个标准，一个FLASH向服务器提出功能调用，索取信息数据的接口标准。用什么语言来制作服务器端的组件并不重要，制做出的组件程序也不重要，重要的是标准，可扩充的标准。一旦行成行业标准，未来就由我们说了算。
或许很困难，或许还有许多别的事可以做，而且这些工作不能仅依靠一批爱好者、开放式源代码的崇拜者来完成，还需要一个有实力的企业来支持。可是我在这里并不是想告诉别人该做什么，而是想提出一些自己的想法，我的知识面不太广，如果有见识不到之处，请诸位指正。
我的邮箱是 [email protected]，欢迎联系。
本文地址：http://com.8s8s.com/it/it7926.htm