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 平台实现桌面应用？
暂无签名
中国开发者画像洞察研究报告 2024
分析开发者的行为模式、工作价值、职业发展等内容，帮助整个行业生态更深入地理解开发者，为他们提供更精准...
评论