大规模视频网站的计费与流量管理
本次分享将会就大规模视频网站的计费与流量管理这个话题，从操作层面细细进行讲解和分析，为系统工程师们揭示平日里我们没有关心的另一些内容。同时也希望本次分享能揭示行业中的一些“潜规则”，让互联网行业的流量与带宽管理更为开放与简洁。
本次演讲视频录制于QCon杭州2011。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
Adobe AIR 1.0——本地操作系统集成问题
作者 Jon Rose 译者 郭晓刚 发布于 2008年2月3日
Adobe AIR平台经常被人诟病的是它缺乏与本地操作系统的集成，而这一点对于构建桌面应用程序通常都是必不可少的。随着AIR 1.0版的发布日趋临近，Adobe的Mike Chambers上周发表了一个概念性的演示，告诉开发者们如何绕过这个问题。
Adobe AIR最常被请求增加的两项特性，一是从AIR应用程序里启动本地可执行文件，另一项是在AIP应用程序里集成本地库的能力。但很不幸，这两项特性都不包含在Adobe AIR 1.0当中。
然而，这并不意味着你就无法让AIR应用程序与底层操作系统集成得更加紧密了。
……
这个项目名为CommandProxy，它在AIR应用程序和底层操作系统之间充当了一个通信代理，理论上它也可以作用于其他基于Web的桌面运行时（例如Mozilla Prism）。不过注意，这个项目完全没有得到Adobe的支持。它仅仅是我搞起来的一个验证性的项目，目的是帮助开发者们理解扩展AIR功能的一种可行途径，让AIR不再局限于运行时所提供的功能。。
Chambers所作的演示相当直观且易于理解，不过它是否充分地揭示了AIR的整个本地问题了呢？Microsoft 传道士Scott Barnes认为答案是否定的，他在给Chambers的回应中批评了AIR平台在本地支持上的不足。
我不知道为什么AIR不想向本地OS开放它的边境，这简直是捡芝麻丢西瓜的写照。要想凭同一个代码包走遍N种平台，肯定有些东西是不得不放弃的。对操作系统的本地访问就是其中之一。任何打算超越自娱自乐阶段的桌面平台，都必须严肃地关注（决定性的）安全问题，并确保建立起行之有效的方案。
Barnes在跟贴中进一步详述了他对Chambers介绍的CommandProxy的顾虑：
命令代理和AIR应用程序之间的信道是一个潜在的弱点。应用程序的开发者应该对机器中遍布着不安全的跨进程通信机制而感到担忧。假设一个进程正监听着一个命名管道，而这个命名管道没有ACL也没有对传入通信的任何验证，那么当有人向管道发送一些垃圾的时候，监听中的进程就完全暴露在所有类型的攻击之下。在使用命令代理的时候，你怎样保护它，防止它变成一个通用的进程启动器呢？
接着Chambers又详细回应了Barnes，一开头就对他自己的概念演示进行了直率的分析：
实际地去构建并部署一个使用了命令代理的应用程序到底可行性如何呢？我的想法是在大多数情况下，由于开发和分发上的复杂性，这种方法是不可行的，虽然在某些情况下它会很有用。
Chambers最后提到了Adobe对这个影响深远的问题的解决计划：
最后，长期的方案（和计划）是让AIR运行时本身提供开发者所需的低级功能。AIR 1.0已经通过若干API提供了对底层操作系统的访问，这些API的覆盖范围会随着新版本的发布一步步地扩大。
那么InfoQ社区中的开发者和架构师们，这方面的顾虑是否阻碍了你将Adobe AIR平台纳入考虑呢？你是否要等到Adobe完全解决了本地集成问题，才会考虑用AIR平台实现桌面应用？
查看英文原文：Adobe AIR 1.0 - Native OS Integration Problem译者 郭晓刚 是InfoQ中文站架构社区编辑，创建并终结过数家软件小企业，翻译过多本技术书籍。
没有回复
关注此讨论 回复