Mozilla Hacks

介绍 WebAPI

头像照片 作者：Robert Nyman [荣誉编辑]

发布于 2011 年 8 月 23 日 分类于 设备 API、特色文章、HTML、移动、Mozilla 和 Web API

Mozilla 想要推出 WebAPI，目标是在 3 到 6 个月内提供基本的 HTML5 手机体验。

现状

如今，开放网络和原生 API 之间存在明显的区别，以及构建方式的不同。许多开发人员都知道，我们需要跨 Web 浏览器、操作系统和设备提供一致的 API，才能构建面向全球的产品，而不仅仅是针对特定设备或供应商。我们需要一种方法将 Web 推向下一步。

什么是 WebAPI？

WebAPI 是 Mozilla 的一项工作，旨在弥合差距，并提供在所有 Web 浏览器中都能正常工作的统一 API，无论操作系统如何。规范草案和实现原型将可用，并将提交给 W3C 进行标准化。安全性在这里是一个非常重要的因素，它将结合现有的安全措施（例如，像地理位置一样请求用户许可）或提出新的替代方案来确保这一点。

在最近的时间范围内，我们正在考虑构建

  • 拨号器：电话和消息 API、联系人 API
  • 通讯录：联系人 API
  • 短信：电话和消息 API、联系人 API
  • 时钟
  • 相机：相机 API、文件系统 API
  • 图库：文件系统 API（可能与 FileReader 和 FileWriter 结合使用）
  • 计算器
  • 设置：设备状态 API、设置 API
  • 游戏：加速度计 API、鼠标锁定 API
  • 地图：地理位置 API、联系人 API

贡献

我们知道有很多才华横溢的人可以提供宝贵的意见，因此请通过以下任何一种方式贡献：

招聘开发人员

我们还正在招聘多名全职工程师参与 WebAPI 的工作。 阅读职位描述并申请。

关于 Robert Nyman [荣誉编辑]

技术布道师和 Mozilla Hacks 编辑。发表关于 HTML5、JavaScript 和开放 Web 的演讲和博客文章。Robert 是 HTML5 和开放 Web 的坚定支持者，自 1999 年以来一直从事 Web 前端开发工作——在瑞典和纽约市。他还定期在 http://robertnyman.com 上发布博客文章，并且热爱旅行和结识新朋友。

更多 Robert Nyman [荣誉编辑] 的文章……

117 条评论

  1. Tomer Cohen

    我希望 Web 可以访问附近的设备，例如使用蓝牙。这将使我们能够直接从浏览器向我们的移动设备发送信息，而无需使用 Firefox Sync 之类的集中同步服务器。

    2011 年 8 月 23 日 03:53

    1. fatriff

      不需要……蓝牙是一项正在消亡的技术……说真的，有什么必要吗？除了 Firefox Sync 之外，还有大量的附加组件和程序仅在家庭网络上运行，用于同步文件、书签和其他内容，而无需使用云。

      2011 年 8 月 23 日 07:05

      1. Natanael L

        消亡？绝对不是！当我和朋友们在一起的时候，我经常使用它！
        你知道，我并不总是连接 Wi-Fi，而且蓝牙在文件传输方面不像 Wi-Fi/3G 那样耗电。
        此外，无线本地文件传输的选择很少。像 Bump 这样的应用程序不适用于非智能手机等设备，也不适用于笔记本电脑（但蓝牙可以）。

        2011 年 8 月 23 日 09:59

    2. Don Park

      手机的点对点蓝牙梦想在蓝牙 1.0 发布的那一刻就破灭了。为了保持“可发现性”而产生的功耗对于手机来说实在太高了。然后是蓝牙攻击的恐慌。此外，我猜测运营商也担心他们无法控制的无线数据网络。

      不过，新的希望出现了，那就是蓝牙 4.0 中的蓝牙低功耗。它完全重新设计，以实现非常低的吞吐量，从而降低功耗。它将使游戏和社交媒体应用程序能够发现房间内拥有相同应用程序/兴趣/等的其他人员。我仍在等待第一款搭载该技术的手机上市，但芯片本身似乎已经进入批量生产阶段。

      2011 年 8 月 23 日 10:19

      1. Jasper Janssen

        我的新 MacBook Air 支持 BT 4.0，包括 LE（据称）。

        如果该制造商的新款手机也采用该技术，我一点也不会感到惊讶。

        2011 年 8 月 23 日 14:39

    3. BrianMB

      以上列表中缺少一项关键的 API：即时通信 API（无论是否通过蓝牙进行，都应由浏览器或操作系统供应商决定）。

      2011 年 8 月 24 日 10:21

      1. Robert Nyman

        是的，这是一个有趣的领域！

        2011 年 8 月 25 日 01:58

        1. L1Blom

          API 应该将蓝牙和 Wi-Fi Direct 作为竞争标准隐藏在一个即时 API 中。

          2011 年 8 月 25 日 08:08

          1. Robert Nyman

            我认为这取决于 API 的类型，但这是其中一种方法。

            2011 年 8 月 25 日 23:09

  2. Cameron McCormack

    WebAPI 项目待办事项列表中的许多规范似乎与 W3C DAP 工作组开发的规范重叠。我们可能已经故意决定不使用这些规范，而是发明新的规范。我实际上还没有看到任何关于这样做的讨论——有讨论过吗？在对这些新 API 进行标准化时，我们会将它们带到 DAP 吗？

    2011 年 8 月 23 日 04:22

    1. Marcos Caceres

      Mozilla 基本上说“那些 W3C/DAP 人员不知道自己在做什么……或者我们不在乎 W3C 在做什么，即使他们已经做了两年了；我们会做得更好，然后将其提交给 W3C 以供批准”，这看起来有点自大。在我看来，这很像当年微软试图使用 XDomainRequest 做的事情。这不是制定标准的好方法。

      2011 年 8 月 24 日 00:07

      1. Robert Nyman

        Marcos，

        情况并非如此。Mozilla 正在尝试不同的方法和技术，从其他项目中学习，并进行原型设计以得出结论。我们的想法是与 W3C 和所有参与者合作，共同找到一个好的解决方案，而不仅仅是将其强加给他们。

        2011 年 8 月 24 日 00:17

      2. John Drinkwater

        请举一个更近的例子，比如 Apple/WebKit 将 CSS 动画提交给 W3C。

        2011 年 8 月 24 日 03:07

        1. Marcos Caceres

          别误会我的意思，如果 W3C 工作组没有处理这些内容（尤其是如果还没有实现），我完全支持将内容提交给他们。无论如何，我期待着看到这一切的结果 :)

          2011 年 8 月 24 日 03:20

          1. Robert Nyman

            不用担心。:-)
            我希望由此产生一些良好的合作！

            2011 年 8 月 24 日 03:58

  3. Shishir Ramam

    虽然在电话 API 中是隐含的，但能够使用/录制麦克风将有助于应用程序交互方面的创新。这在各种领域都非常有用——早期教育、残疾人辅助功能以及纯粹的娱乐！

    2011 年 8 月 23 日 04:48

    1. Gerardo Capiel

      我赞同这一点，以及对 TTS API 的需求，以实现自语音应用程序，这将对免视应用程序和辅助功能很有用。Google 在 Web 应用程序和扩展程序的 TTS 方面做了一些不错的工作，请参阅

      http://code.google.com/chrome/extensions/trunk/tts.html

      通用辅助功能 API 也很好。Apple 围绕此问题提出了一个 W3C 建议

      http://lists.w3.org/Archives/Public/wai-xtech/2010Aug/att-0079/UserInterfaceIndependence.html

      2011 年 8 月 23 日 08:03

      1. Robert Nyman

        当然，这里有很多有趣的选项！

        2011 年 8 月 23 日 14:55

    2. Jay Fienberg

      我也想提出这一点：移动设备通常配有麦克风和扬声器，是自然的音频设备。同时，HTML5/Javascript 中也越来越多地用于在浏览器中播放和处理音频。

      上面列出的“图库 API”概念可能针对照片和视频，但对于仅限音频的媒体也有类似的需求——要么“图库”包含各种媒体，要么更广泛的“媒体库”API 可以作为照片、音频、视频、混合等媒体的总称。

      2011 年 8 月 23 日 14:53

      1. Robert Nyman

        我同意。我相信这是探索和构建的基础，以考虑诸如此类的事情。

        2011 年 8 月 23 日 14:57

  4. Tim

    我不确定您指的是仅仅一个 API，还是 Firefox 移动产品，或者像 PhoneGap 这样的外部框架。你们真的应该专注于 PhoneGap 尚未提供的其他主要原生功能，日历和推送通知似乎在您的列表中缺失（我希望您在拨号器 API 中也提供通话记录）。

    2011 年 8 月 23 日 04:54

  5. Robert Nyman [Mozilla - 文章作者]

    感谢您的评论！

    Tomer，

    蓝牙听起来确实很有趣！然而，它不在最初的步骤中，但也许有一天会。

    Cameron，

    我不确定该过程究竟是如何进行的，但我希望能够了解，并会回复您/此页面。

    Shishir，

    这确实可能非常令人兴奋！

    Tim，

    这是一组 API，旨在进行标准化并由所有人实现。我同意日历和推送听起来很有趣！

    2011 年 8 月 23 日 05:16

    1. Natanael L

      还有 NFC、陀螺仪等……
      实际上，可以支持相当多的硬件，我不知道如何确定优先级。

      2011 年 8 月 23 日 10:01

      1. John Drinkwater

        WebNFC 已计划 https://bugzilla.mozilla.org/show_bug.cgi?id=674741
        陀螺仪应该已经得到支持 https://hacks.mozilla.ac.cn/2009/10/orientation-for-firefox/

        2011 年 8 月 24 日 03:10

        1. Robert Nyman

          谢谢 John！

          2011 年 8 月 24 日 03:59

  6. Jonas Arnklint

    酷，很棒的举措！

    2011 年 8 月 23 日 05:17

  7. Marty Zalega

    我认为这是一个很好的方向，但我认为这个愿景过于狭窄，并且过于针对移动设备。桌面和移动设备之间的唯一区别是外形尺寸。虽然我想要访问摄像头和用户的地址簿，但我认为这个概念需要更广泛，并且应该允许 Web 应用执行原生应用可以执行的任何操作，只要用户允许即可。如果用户拥有扫描仪并授权，则应用应该被允许使用它。蓝牙和打印机等其他组件也是如此。我承认，这听起来确实过于雄心勃勃，但对于大多数组件来说，都存在最低公分母。例如，扫描仪和摄像头等都属于图像范畴，可以有一个统一的接口。浏览器正在成为操作系统的理念是错误的。浏览器应该是管道。

    2011年8月23日 06:04

    1. Chris B

      我想反驳的是，移动设备和桌面设备之间存在着有意义的区别——不仅仅是外形尺寸问题。便携性，以及由此产生的位置相关信息的关联性，对于移动设备来说非常重要，但对于桌面设备来说则不然。另一个例子是摄像头——在桌面设备上，摄像头几乎100%的时间用于捕获用户的视频，用于双向视频聊天。在移动设备上，摄像头更多地用于拍摄用户周围环境的照片（和视频）——双向视频聊天作为一项独立功能，直到最近才开始流行。

      2011年8月23日 23:52

      1. Robert Nyman

        绝对的，并且创建对某些设备和用例功能强大的 API 将会很有趣，而这些 API 在例如台式计算机上则会更加基础——但仍然需要确保它们在所有情况下都能发挥作用。

        2011年8月24日 00:03

      2. Bruno Torquato

        在某个平台上，某些类型的使用方式更为普遍，确实存在一些有意义的区别，但我认为，这一观察结果与 API 应该启用的功能几乎没有关系。移动设备更多地用于拍摄快照而不是双向视频聊天，但这并不妨碍它进行双向视频聊天。地理位置服务与移动设备的相关性更高，但这并不妨碍它成为基于桌面操作系统的 Web 体验的重要组成部分，尤其是在人们越来越倾向于选择笔记本电脑而不是台式电脑的情况下，并且像 MacBook Air 这样的产品正在模糊移动和桌面体验之间的界限。“一个 Web”应该意味着“一个 Web”，而不是一个移动 Web 和一个桌面 Web。不应该将设备的操作系统作为广泛推断使用方式的方法。

        2011年8月24日 07:18

        1. Robert Nyman

          不，我的意思是，在某些情况下，某些功能将可用，例如，在移动设备上可用，但在台式机/笔记本电脑上不可用。例如，大多数设备不支持加速计，并且可能永远都不会支持。但是，API 应该仍然存在，然后开发人员可以根据 API 的响应采取行动。

          2011年8月24日 07:29

  8. Will

    举个例子：从 hn 上的链接到我 iPhone 上的这个页面，我得到的是一个桌面网页，并且电子邮件字段没有正确的“灵丹妙药”来将我的键盘切换到电子邮件模式，而项目页面的链接则给我一个白屏。有人负责一个项目的开发，该项目用于创建足够有用的工具来简化“移动化”过程，这对于解决此问题至关重要。点赞。

    2011年8月23日 06:22

  9. Alex

    这是一个很棒的计划！我希望它能取得成果，但不幸的是，我不认为苹果会配合这个计划。

    2011年8月23日 06:31

  10. David Crone

    您是否会考虑如何扩展 HTML5 元素以支持一种标准的内容加密和 DRM 方法？如果没有这些，大量的內容将无法在各种设备生态系统中以真正标准的方式提供，因为内容提供商将不支持它。

    2011年8月23日 06:36

    1. David Crone

      这应该写成 HTML5 视频元素（因为它因为我尝试使用尖括号而变得混乱 :-))

      2011年8月23日 06:37

  11. Robert Nyman [Mozilla - 文章作者]

    Jonas，

    谢谢！

    Marty，

    很有意思的想法！我认为这是一个开始，然后我们将看看它的发展方向以及它能带我们走向何方。

    Will，

    我相信这是很多事情的结果，比如教人们如何去做，什么是共同点等等。工具也很重要，但在那之后，我们需要更多 API 和类似的东西来尽可能轻松地检测和执行某些操作。

    David，

    谈到加密，这绝对很有趣。对于 DRM 来说，在某些情况下它很重要，但我并不确定 DRM 将如何融入其中。

    不过，这超出了 WebAPI 的范围，至少目前是这样。

    2011年8月23日 06:43

  12. Matthew Phillips

    我业余时间开始开发一个手机应用。源代码可以从这里获取

    https://github.com/matthewp/b2g-phoney

    当然，由于电话 API 尚未发展到足够完善的程度，因此无法拨打电话。

    不过，这里有一个需要解决的问题：虽然许多“拨号器”应用可以拨打电话，但只有一个应用可以接听。需要有一种方法来获取权限，以成为默认的电话接听应用。然后，当收到来电时，B2G 会将呼叫路由到默认应用。我建议使用

    bool ringing()

    应用可以在启动时调用此函数。如果它返回 false，则没有呼叫要接收。如果它返回 true，则应用可以提示用户接听或挂断。

    2011年8月23日 07:25

  13. N.V.Balaji

    听到这个消息非常令人兴奋——WebAPI 的开发将极大地加速“浏览器作为平台”的范式。时间表看起来很有野心！

    我想知道您打算如何管理应用程序框架——例如以下问题
    1. 应用转到前台或后台，
    2. 应用调用另一个应用的功能（类似于 Web 意图），
    3. 应用在启动时被调用，
    4. 应用没有 UI（更像是一种服务）
    5. 应用向系统中的所有监听器发送一些信息

    2011年8月23日 07:28

  14. Kamil Trebunia

    这与：http://www.w3.org/2009/dap/ 有什么关系？

    2011年8月23日 08:13

  15. Cole

    请移除联系人 API。将其作为用户选择的应用程序更有意义。

    2011年8月23日 08:41

  16. Robert

    我一直希望拥有这些功能——但是您能想出一个更好的名称吗？

    2011年8月23日 08:44

  17. Alexander Kanavin

    此外，这与http://www.wacapps.net/specifications 有什么关系？
    您是否在重复他们已经完成的工作？

    2011年8月23日 09:12

  18. Richard

    你们打算如何在不将类似 ActiveX 的漏洞引入 Firefox 的情况下实现这一点？

    2011年8月23日 09:16

  19. Amit Naik

    Mozilla 做了一项非常棒的工作——但是否有其他任何人表示愿意加入这项计划？

    标准的优劣取决于它所吸引的社区，除非像 Google、Apple、Microsoft 等其他一些参与者也表现出兴趣，否则这将最终沦为另一个 API。

    2011年8月23日 09:43

  20. Robert Nyman

    fatriff，

    不确定蓝牙是否是一项即将淘汰的技术，但决定权不在我手中。

    Matthew，

    很有意思，感谢分享！
    关于接听电话，这是一个很好的观点，我希望它会被牢记在心。

    N.V.Balaji，

    所有这些都是很好的问题，目前我不确定是否已经决定。请尝试访问WebAPI 讨论组。

    Kamil，

    有些想法是类似的，但在其他方面可能存在不同的目标。

    Cole，

    我相信在某些情况下，访问联系人将是必要且有用的。

    Robert，

    好吧，这就是目前的名字，但我们始终乐于接受建议。:-)

    Alexander，

    我不了解这些规范的具体细节，但我相信将会存在合作和灵感。

    Richard，

    我现在无法透露 Firefox 或任何其他 Web 浏览器/设备的实现细节。但是，如果您在这方面有经验，请在WebAPI 讨论组中分享。

    Amit，

    这是第一步，目标是让它发展成为/成为规范的一部分，以便适用于所有人。

    2011年8月23日 09:49

  21. Chad Smith

    这是一个很棒的想法，很高兴看到它正在发生。我有一家从事类似业务的公司，但并不完全相同。它名为 The Easy API——http://theeasyapi.com——我看到了所有其他开发人员都面临的同样的困境。我决定开始构建一个 API，该 API 将包含和封装其他 API，从而提供一个单一的 API 进行编码并获得所有其他 API 的强大功能。此外，它使我能够在可能的情况下缓存一些结果。我在 2010 年 2 月将其开放给其他开发人员，并在 2011 年 10 月中旬开始跟踪请求。The Easy API 每天处理约 250,000 多个请求，并被各种公司使用。

    我将继续关注这个项目，因为它与我息息相关。我还会寻找可以提供帮助的方式，如果您有任何具体需要帮助的事情，请告诉我。

    保重，
    Chad

    2011年8月23日 10:53

    1. Natanael L

      这些类似 Android 意图的“元 API”想法已经讨论过了。
      https://bugzilla.mozilla.org/show_bug.cgi?id=674720

      :)

      2011年8月24日 03:25

      1. Natanael L

        找到了另一个
        https://groups.google.com/group/mozilla.dev.webapi/browse_thread/thread/68ef6753fe663141/5fc1e8545a7e8b3e#5fc1e8545a7e8b3e

        2011年8月24日 03:27

        1. Robert Nyman

          感谢 Natanael！

          2011年8月24日 04:00

  22. 一个热爱 Firefox 的人

    我真的很抱歉说了这些话，但我对此感到厌倦了。Mozilla，别再开发没人需要的垃圾了，看在上帝的份上，让 Firefox 更快，更省资源！

    2011年8月23日 11:34

  23. Chad Selph

    “WebAPI”？您能为这些标准选择一个更模糊的名字吗？

    2011年8月23日 11:55

  24. Robert Nyman

    Chad，

    谢谢，听起来很棒！请查看这篇博文中有关如何贡献的部分，随时欢迎您提出想法！

    一个热爱 Firefox 的人，

    很抱歉您有这种感觉。Mozilla 的目标是保持网络开放，并为开发人员和用户提供开放的标准、工具和技术。我们认为这在移动领域非常重要，并且鉴于该领域类似的项目和努力，这似乎是一个有充分根据的观点。

    我们自然也会继续改进 Firefox，使其尽可能出色。

    Chad，

    该想法是通常为 Web 层提供各种 API，但我理解这个术语并不是那么具有描述性。

    2011年8月23日 13:39

  25. Walter loose

    为什么不为每个平台创建一个处理这些 API 的 Firefox 浏览器？

    2011年8月23日 14:00

    1. Stuart Carnie

      某些平台存在特定的限制，Mozilla 无法包含 API 所需的所有必要功能。例如，Apple 需要在 Mobile Safari/WebKit 中包含这些功能。

      2011 年 8 月 23 日 14:39

  26. Robert Nyman

    Walter，

    目标是拥有无论 Web 浏览器和操作系统是什么都能工作的 API。自然，Firefox 将在 Firefox 可用的环境中支持这些 API。

    2011年8月23日 14:18

  27. Lee

    当我想到这么多聪明人花费无数小时试图通过浏览器重新创建我们几十年来已经拥有的东西时，我的头都大了。我们真的需要花费时间通过浏览器重新创建基本的操作系统功能（包括文件存储等）吗？说真的，为什么？不存在编写一次，随处运行的情况。如果存在，则意味着任何类型的差异化或突破性技术都将消亡，因为编写一次，随处运行不需要任何偏差。

    2011年8月23日 14:32

  28. Kamil Trebunia

    如果那些其他技术如此出色，那么它们将超越开放 Web，而不是像现在这样反过来——是开放 Web 越来越多地接管传统的技术栈。

    2011年8月23日 14:36

  29. Robert Nyman

    Lee，

    这里有很多因素，但其中一个主要因素是，由于存在各种不同的操作系统和设备，因此为每个设备开发单独的应用程序的成本非常高，而且浪费时间。最重要的是，问题在于，各种应用商店和操作系统的拥有者决定您可以为其开发什么，以及允许您部署什么。

    我宁愿说差异化在于用户体验等方面，而不是 API 访问是来自原生代码还是 Web 代码。

    2011年8月23日 14:45

  30. Gabriel

    是否有可能包含流音频？台式机和移动设备都可以从 VoIP、流媒体广播和其他形式的实时音频上传/下载服务中受益。现在不得不使用 Flash 真是太可惜了。

    2011年8月23日 15:37

  31. J.D.

    根据这种推理，当今的每种流行产品都是“好的”，因为它很流行。

    您所说的“开放 Web”之所以能够获胜，是因为它对新用户来说很容易。它针对入门进行了优化。这仅仅是质量的一个方面。

    你同样可以反驳说，如果说，“麦田守望者”如此优秀，它应该在销量上超过“暮光之城”（或“加菲猫”），而不是反过来。而“暮光之城”无疑非常擅长卖书（和电影），但声称它总体上很好是因为它在这件事上做得好，这是循环论证。

    追随当前的流行趋势可能是抓住上升浪潮并从中短期获利的好方法。但这不是一个好的长期投资。我们今天认为伟大的大多数艺术作品在其创作之初并不流行。这些 API 可能持续发展并繁荣，也可能很快消失，但现在几乎不可能预测。

    网络正在成为一个大型的元平台，现在我们有足够的性能可以浪费在这种事情上。它比过去几十年的操作系统研究更好吗？据我所知，只有在政治上它才更好：操作系统充满了如此有争议的问题，以至于网络领域的人们在构建一个绕过所有现有操作系统争端的新的层次上取得了巨大的成功。为网络创建一个新的“文件系统 API”来抽象化所有内容（并且比 20 世纪 80 年代的文件系统更简单、功能更弱）比让甚至两个操作系统供应商就任何事情达成一致都要容易。

    网络在分发和安装方面表现更好，通常（但并非总是）是以牺牲其他几乎所有方面为代价的。

    2011 年 8 月 23 日 16:05

  32. John

    你的愿望清单首位是 DRM？笑死我了！

    2011 年 8 月 23 日 16:17

  33. Ben Vitale

    我赞同之前关于 W3C DAP 的评论，并想知道这项工作是否已经开始。

    2011 年 8 月 23 日 16:54

  34. James

    请参考 http://xkcd.com/927/，然后采用 14 个现有提案中的一个。

    2011 年 8 月 23 日 17:01

  35. Ben Vitale

    DAP 小组当然对参与感兴趣。

    http://lists.w3.org/Archives/Public/public-device-apis/2011Aug/0051.html

    2011 年 8 月 23 日 17:02

  36. Andrew

    在未来 3-6 个月内，包含涵盖 CRUD 的日历 API 将非常棒，因为它似乎在 W3C DAP 小组中停滞不前。

    2011 年 8 月 23 日 17:02

  37. Jason

    包含文件系统 API 是否意味着将尝试实现 W3C 文件 API 中包含系统和目录的部分？

    还是其他什么？

    2011 年 8 月 23 日 17:09

  38. Robert Nyman

    Gabriel,

    我认为那更像是 HTML5 本身的工作，但我同意，获得它非常重要。

    J.D.,

    关于开放网络，我首先要说它之所以重要仅仅因为它开放。它不属于任何公司或团体，任何人都可以使用并参与开放标准。

    对于 Mozilla 来说，这绝对不是关于当前流行什么，而是关于我们认为对网络有益并符合我们的使命的事情。

    John,

    不过，对于一些个人、组织和媒体来说，DRM 非常重要，所以我理解这种愿望。

    Ben,

    目前尚不清楚它将如何工作，但 Mozilla 的工作范围比 W3C DAP 的当前工作范围更广。我希望 WebAPI 能回到 W3C，我们能找到一个让每个人都受益的解决方案，并且我们可以共同努力。

    James,

    Mozilla 的想法和目标不包括在其中，但通过将结果放回 W3C，我希望它最终能融入现有的某个提案，或者两个或多个提案能够合并。

    Andrew,

    是的，那将非常棒。

    Jason,

    目前尚不清楚它将涵盖什么内容，但最初我想说的是读取和写入文件。

    2011 年 8 月 24 日 00:04

  39. Archaeopteryx

    为计算器实现欢呼，不再需要利用漏洞来启动它了。

    （抱歉，这条评论没有建设性，但我忍不住。）

    2011 年 8 月 24 日 00:48

  40. Robert Nyman

    Archaeopteryx,

    我很高兴你对此感到高兴。:-)

    2011 年 8 月 24 日 00:51

  41. Andrew Ozz

    这听起来都很好，但是 contentEditable/designMode 呢？浏览器中的所见即所得编辑已经存在很长时间了（10 多年），但仍然没有标准化。它在非常简单的文本格式化方面效果很好，但一旦你尝试更高级的 HTML，它就会崩溃。

    考虑到目前很多网络内容都是通过浏览器发布的，而且将来只会越来越多，所以这样一个有用的功能却受到如此少的关注，这令人感到遗憾。

    我知道有几个非常好的基于 JavaScript 的编辑器（我为其中一个做贡献），但如果浏览器中内置了标准化的、强大的编辑支持，请想象一下可能性。

    2011 年 8 月 24 日 07:05

  42. Fabio

    你不知道……现在拥有它将非常有用！……
    很棒的项目，伙计们！我会告诉我的很多开发者朋友。

    Ciao! F.

    2011 年 8 月 24 日 07:09

  43. Robert Nyman

    Andrew,

    我同意 contentEditable 确实需要更多关注和工作，但它远超出 WebAPI 的范围。

    Fabio,

    谢谢，很高兴你喜欢它！

    2011 年 8 月 24 日 07:36

  44. Davison

    我也同意这项计划的范围不应仅限于移动设备。如果有一种方法可以让在 Web 浏览器中运行的代码与系统硬件甚至系统上运行的其他软件交互，那么我们就可以拥有最终能够像真正的桌面应用程序一样工作的 Web 应用程序。

    确实，这种接口的含义肯定会很复杂，需要关注安全性和系统稳定性，但好处将证明花在这些事情上的时间是值得的。想象一下，最终能够创建一个既拥有 jQuery 的强大功能又拥有浏览器可移植性的应用程序，但还可以直接从 JavaScript 打印到标签打印机（无需弹出标准打印机对话框）。想想自助服务终端、POS 系统以及各种其他可能的应用程序。现在，唯一可以做到这一点的方法是创建一些基于较低级语言和过时插件体系结构的复杂且笨拙的插件。

    拥有一个基于 JavaScript 的 API 来访问系统正是我多年来一直想要的。

    2011 年 8 月 24 日 21:10

    1. Robert Nyman

      我同意，有大量的用例可以使事情变得更容易。但我认为现在重要的是测试它并对其进行原型设计，一次一步，看看我们究竟可以将其带到哪里。

      2011 年 8 月 25 日 01:59

  45. Scott Wilson

    最好在开头明确承诺与 DAP 和 WAC 合作，而不是让人产生“去他的，我们最了解！”的印象。

    不要说“将结果放回 W3C”之类的话。从一开始就作为一个真正的社区共同努力。这只不过是在邮件列表中发布一些帖子而已。

    2011 年 8 月 25 日 01:27

    1. Robert Nyman

      我们的想法不是仅仅忽略 W3C DAP、WAC 及其工作，而是尝试一些它们没有完全涵盖的事情。

      至少对我来说，进行测试用例并提出方法和建议不仅仅是发邮件列表帖子。

      2011 年 8 月 25 日 02:02

      1. Scott Wilson

        （作为一名 Apache 提交者，我所做的很多关于进行测试用例并提出方法和建议的事情基本上就是在邮件列表中发帖！W3C 也是如此。我认为 Moz 也没什么不同……）

        我认为关于基本相同的功能（联系人 API、相机 API 等）进行单独的讨论毫无帮助。

        顺便问一下，你认为哪些内容没有涵盖？我在上面的列表中没有看到任何不在 DAP、HTML5、WHATWG 或 WAC 中的内容。

        2011 年 8 月 25 日 02:15

        1. Robert Nyman

          该列表非常基础，是最初的步骤，但据我从团队那里了解到的情况，他们有一些想法和思考超出了 W3C DAP 的范围。

          我同意，如果随着时间的推移，我们能找到一个良好的合作方式，避免对同一件事进行冗余讨论，那将非常棒！

          请将此视为第一步，随着时间的推移，我希望所有这些问题和担忧都能得到解决。

          2011 年 8 月 25 日 03:10

  46. Chris K

    @fatriff – 蓝牙的用途不仅仅是同步，但我同意同步是我对 Tomer 描述的情况的首选工具。也就是说，Mozilla 的成立宗旨是让用户拥有选择权，因此如果 Tomer 想制作一个 FF 插件/附加组件，我完全支持这个想法。

    2011 年 8 月 25 日 07:12

  47. Gerard Braad

    由于 B2G 距离存在还很遥远，那么将使用什么作为基础平台来开始这些 API 的开发？

    2011 年 8 月 25 日 19:28

    1. Robert Nyman

      我相信正在为各种平台进行原型设计，但没有更多细节。如果您想与他们更多地讨论此事，请查看文章中关于如何贡献的部分。

      2011 年 8 月 25 日 23:11

  48. Yop

    拜托，我只需要一个能在 30 秒内打开的浏览器。

    2011 年 8 月 26 日 13:24

  49. patrick21

    必须实现蓝牙。我为一家德国软件开发公司工作，并使用很多与加热、EC 卡读取器等测量设备相关的程序，这些设备通过移动设备的蓝牙连接。如果没有某种接口，我就无法将用 C# 编写的程序转换为 HTML5，但我希望这样做……是否有任何计划？红外线已死，但蓝牙通信在我看来是必须的。

    2011 年 8 月 27 日 09:08

  50. patrick21

    我需要在蓝牙帖子中添加一些内容……能够将数据从我的移动设备同步到台式电脑会非常方便。想象一个在手机上收集数据并将其直接发送到桌面对应应用程序的应用程序，反之亦然，如果它通过蓝牙连接进行同步，无需在线。例如，发送一个 SQLite 数据库或一个文件以导入它。我的英语不好，抱歉，但你们是唯一负责 HTML5 标准的人，我觉得它将是未来的发展方向。德国这边没有人讨论这些问题 :(

    2011 年 8 月 27 日 09:23

  51. Reg

    抱歉又引发了一轮嘲笑，但我们组织的首要问题是 DRM。我们提供互联网点播视频解决方案，任何不允许我们合理尝试保护客户内容免遭盗窃的交付机制都不会被考虑。长期以来，最受欢迎的解决方案是 Flash，但现在客户开始坚持使用 Silverlight。

    理想情况下，我们能够利用超出浏览器控制范围的解密功能——尤其是开源浏览器（无意冒犯）。这可能是将加密视频流传递给 HDMI 设备。毕竟 IPTV 已经出现了——或者说几乎出现了。

    并非每个人都会使用 HDMI 设备，并且较低质量的流通常不需要如此严格的保护。能够推出一个包含我们自己的解密功能的编解码器的原生版本将是很好的。

    2011 年 8 月 28 日 15:20

    1. Robert Nyman

      我理解对 DRM 的需求，它不会消失。不过，我想说它目前不在 WebAPI 的范围内。只有未来才能说明 DRM 及其解决方案将如何发展。

      2011 年 8 月 29 日 05:51

    2. Natanael L

      DRM 从来都不起作用。只需要一个人找出如何破解它，然后它就被破解了。
      将这一事实与开源结合起来，然后……

      2011 年 8 月 29 日 05:59

      1. Robert Nyman

        我认为，无论观点如何，很多组织都需要 DRM 来共享他们共享的内容（想想各种媒体公司等）。最终，即使它被破解了，我相信这仍然是为了让人们更难共享他们不拥有的内容。

        2011 年 8 月 29 日 06:35

        1. Natanael L

          然而，它只给诚实的人带来不便，而只有“不那么诚实”的人中的最初黑客才能从中受益。

          2011 年 8 月 29 日 06:57

          1. Robert Nyman

            我同意大多数 DRM 实现对大多数用户来说都是一个麻烦，是的。

            2011 年 8 月 29 日 07:03

    3. Foo Bar

      音频/视频内容上的 DRM 从物理上来说是不可能的。

      即使软件方案无法被击败，任何人都可以将音频/视频输出连接到采集卡，或者只是用相机对准屏幕或将麦克风连接到扬声器（如果操作得当，质量损失可以忽略不计）。

      你唯一可以成功使用 DRM 的是游戏机游戏，前提是游戏机平台为其设计得当。

      2011 年 9 月 3 日 16:09

      1. Robert Nyman

        我们知道这一点，但我认为这更像是让最终用户更难操作，从而希望他们不会费力去破解它。

        2011 年 9 月 5 日 01:37

  52. Fredrik Söderström

    这太棒了，我迫不及待地想使用它！

    这是保持网络开放而不是让所有内容都变成闭源应用程序的好方法。

    2011 年 8 月 31 日 11:19

    1. Robert Nyman

      谢谢，很高兴听到这个消息！

      2011 年 9 月 1 日 02:40

  53. Julien Gouesse

    请不要使用 DRM。这不是我对 Mozilla 基金会的期望！这绝对不可接受。维护 DRM 等于维护一种保护行业的技术手段，这些行业拒绝调整其商业模式，这不是我对开源产品的期望。在 WebAPI 中支持 DRM 意味着你计划赋予企业更多权力，而赋予用户更少权力，这与绝大多数免费开源软件所采取的方向完全相反。DRM 危及我们的权利，它允许禁用功能、阻止产品、审查和删除内容，甚至无需用户同意。在 WebAPI 中加入这样的东西会导致在桌面和嵌入式环境中远程允许此类操作。不要为了增加他们的利润而牺牲我们的自由。我们的生命比他们的利润更有价值！对 DRM 说不，对尊重我们权利的免费开源软件说 yes！

    2011 年 9 月 1 日 06:07

    1. Robert Nyman

      我理解您对DRM的强烈意见，并且我在上面已经提到过它根本不在WebAPI的范围内。不过，我个人想说的是，出于许多法律原因，许多媒体机构需要对其内容进行一定程度的保护——而HTML5目前无法提供这种保护。

      所以，我理解市场对此有需求，但我认为Mozilla不会投入精力来启用DRM。

      2011年9月1日 07:15

  54. Julien Gouesse

    感谢您对此的澄清。依我拙见，世界可以没有DRM，市场也必须发展到不再需要对内容进行如此控制的地步。如果市场拒绝进化，我们绝不应该以任何危及我们权利的方式鼓励它保留“旧”机制。

    正如您所说，DRM在技术上不在WebAPI的范围内，这一点很清楚。也许我对Mozilla基金会期望过高，但即使是限制用户自由使用已购买产品的原则也不应该被容忍。

    2011年9月1日 07:53

    1. Robert Nyman

      就我个人而言，我也不相信DRM。但我确实同情一些开发者/组织必须面对的问题。

      正如您提到的，从Mozilla的角度来看，我们开展各种活动来促进开放和开放网络，并且我们旨在帮助提供开放的替代方案。

      2011年9月1日 08:34

  55. David Rogers

    抱歉回复晚了。虽然我很高兴Mozilla终于在设备API方面取得了进展，但同样令人沮丧的是，在过去的三年里，他们拒绝参与OMTP BONDI、W3C DAP和WAC在这方面的工作。范围一直存在扩展的可能性，并且您本可以轻松地为我和其他人撰写的章程做出贡献。从上面的评论中仍然不清楚您是否打算完全参与DAP正在进行的努力，并使之真正跨浏览器和跨行业。此外，请您解释一下您打算如何处理访问安全和不同的用户需求，例如隐私？

    2011年9月2日 03:22

    1. Robert Nyman

      我个人当时不在Mozilla工作，我对历史了解不多，无法对此发表评论。希望后续博客文章能解决您的一些问题。

      2011年9月2日 03:29

  56. Daniel Pavlic

    您好，

    WebAPI项目看起来非常有趣。但是，我在您的规范中没有看到任何关于该元素的参考。我认为为在画布上绘制对象创建一个API将是一个非常好的主意，这将使创建GUI比现在容易得多。之前的Mozilla SkyWriter项目（现在是http://cloud9ide.com/）已经实现了这一点。发布这个引擎将是很棒的，这样每个人都可以使用它。这是WebAPI项目的一部分吗？

    2011年10月7日 14:54

    1. Robert Nyman

      目前这不是WebAPI项目的一部分，但我同意看到它会很好。我们将看看它的发展情况。

      2011年10月8日 15:03

  57. Daniel Pavlic

    嗨，Robert，感谢您的回复。如果用于在HTML canvas元素上绘制的引擎不是WebAPI项目的一部分，并且如果我正确理解了之前SkyWriter（即之前的Bespin项目）的成就（http://benzilla.galbraiths.org/2009/02/17/bespin-and-canvas/），那么在我看来，Mozilla Labs在两年前就已经创建了一个用于在画布上绘制的引擎？如何创建这些菜单、选项卡、按钮等？Bespin项目肯定创建了一个API，这样您就可以说例如WINDOW(x,y,length,height)，然后您在画布上得到一个窗口，您可以拖动、最小化、最大化，并在上面放置按钮等等。我没有深入研究现在的Cloud9 IDE，我只是阅读了关于Bespin的博文，并且看到了IDE的屏幕截图，所以可能遗漏了一些东西。

    2011年10月8日 17:54

  58. Majid

    很棒的工作！

    2012年4月17日 02:18

    1. Robert Nyman

      谢谢！

      2012年4月17日 03:53

  59. Davy McAleer

    嗨，Robert，
    首先，您回复所有各种请求和意见，真是耐心十足！
    现在考虑这个问题可能还为时过早，但目前Android与Apple之间的一个大问题是在企业环境中安全控制设备的能力以及消费者和企业用户的整体安全级别。是否考虑过创建MDM（移动设备管理）API来启用加密、远程实施设置和限制以及在设备丢失时锁定和擦除类型功能？
    Android OEM以一种非常零散的方式实现了这一点，这极大地降低了这些设备在企业环境中的实用性——随着BYOD策略越来越普遍，Apple在安全方面现在对企业和消费者来说更有吸引力。
    只是想知道你们是否考虑过远程管理B2G设备或某种形式的权限类型角色功能，以便能够访问您的API，如果其中一家MDM公司创建了一个在设备上运行并访问您公开的所有API的应用程序。
    谢谢，并期待看到这些东西出现在现实世界中——向所有那些敬业的开源贡献者致敬！
    此致
    Davy

    2012年4月22日 13:34

    1. Robert Nyman

      >首先，您回复所有各种请求和意见，真是耐心十足！

      谢谢！:-)

      对于WebAPI的当前状态和未来计划，我个人目前没有了解到正在进行的工作。但请关注WebAPI页面以查看进度！

      2012年4月24日 15:04

  60. Gene Vayngrib

    这真是太迟了！W3C在这个领域慢得令人难以置信。而且Apple不会在Safari中推动设备API，因为它会扰乱其App Store。Google在这个问题上的行为与Apple完全相同。我们四年前通过创建围绕webkit的shell，尝试用我们自己的项目bhoost.com来解决这个问题，并且知道这不是一件容易的事。问题在于人们想要使用常规浏览器，而不是下载一个提供对设备WebAPI访问权限的特殊浏览器。因此，Mozilla加入这场游戏最终可能使访问设备WebAPI的Web应用程序成为现实。此外，这将使Mozilla更具优势。想象一下，一个流行的设备启用Web应用程序仅在Mozilla上运行一段时间，直到WebKit赶上来。这个应用程序可能是Facebook Messenger，因为Facebook大力推动HTML5议程而不是原生应用程序，或者它可能是全新的东西。

    一些想法
    1. 很酷的一点是，在JS中能够检查浏览器是否支持设备API。这样我们就可以提示用户下载Mozilla浏览器。
    2. 为了与原生应用程序竞争，我们需要一种在主屏幕上注册图标的简单方法。
    3. 为了与原生应用程序竞争，我们需要Web应用程序能够在后台运行，或者在某些设备事件发生时唤醒。
    4. 为了与原生应用程序竞争，我们需要一种自动启动浏览器后台组件和某些启动Web应用程序的方法。想象一下，如果用户在手机重启后需要手动启动电话和短信应用程序。如果没有此功能，您无法编写一个在一些朋友在附近时提醒我的Web应用程序。

    2012年4月27日 19:24

    1. Robert Nyman

      是的，我们希望将所有内容标准化，并希望所有主要参与者都将效仿。

      关于这些想法

      1. 通常，这取决于您要使用哪种API，而不是对所有API进行集体检查。此外，包含的API数量一直在变化，因此维护它是不现实的。

      2. 我完全同意。

      3. 平台相关，但是的，它们应该能够在后台运行。

      4. 对于电话和短信来说，我认为这取决于哪个应用程序有权访问它，以及如何在后台检测事物。

      2012年4月29日 08:42

  61. Gene Vayngrib

    Robert，感谢您的回复。
    1. 没错，最好在每个功能的基础上进行检查。这可以成为新API的一部分吗？这样，我们就不需要想出一些巧妙且总是不同的发现机制。
    4. 也许我表达得不够清楚。我指的是电话和短信作为手机重启后自动启动的应用程序的示例。如果我要创建新的Siri、新的增强现实应用程序、新的社交发现应用程序，这些应用程序会对用户所在的环境和周围环境做出反应，我需要依赖我的Web应用程序在手机重启后启动的事实。

    2012年4月29日 08:53

    1. Robert Nyman

      1. 好吧，希望一般的功能检测应该有效。例如，如果Web浏览器没有完全实现某个方法，则不应声称支持该方法。

      4. 哦，我明白了。目前不确定我们在这方面的确切立场，但我同意。

      2012年5月8日 05:49

  62. Aravind R S

    B2G中是否有任何计划允许Web应用程序相互交互的API？我认为对于像Android Intent（WebIntent？）这样的简单交互肯定存在用例。

    可能还需要类似于后台服务的东西，设备上的其他应用程序可以通过类似于RPC的东西与之通信。

    Intent用例：用户可以安装多个提供各种社交网络上“分享”功能的应用程序；具有可以共享内容的应用程序可以触发一个通用的“分享”intent，然后用户可以在提供该功能的应用程序中进行选择。

    Intent/Services用例：用户可能有多个来自不同网站的互联网广播应用程序，以及一个通用的“音乐中心”应用程序。音乐中心应用程序应该能够获取已安装的具有“音乐播放服务”功能的应用程序列表，启动/停止服务，并向它们发送暂停/播放等消息。

    2012年7月12日 07:24

    1. Robert Nyman

      Intent和跨应用程序工作确实很有趣！目前尚不清楚具体将如何实现，但我希望我们能在那里看到一些良好的进展！

      2012年7月31日 08:28

  63. robert

    我认为这第一行
    Mozilla希望推出WebAPI，目标是在3到6个月内提供基本的HTML5手机体验。

    具有很大的误导性。据我这个新手了解，WebAPI试图增加跨浏览器API的数量。它们并非专门针对移动设备或手机。

    2012年7月16日 11:53

    1. Robert Nyman

      如果您看到了Firefox OS的进展，以及其他移动供应商效仿的希望，这正是现在已经实现的第一个目标。

      然后，当然，我们希望尽可能多的API跨浏览器，无论平台如何。

      2012年7月31日 08:31

  64. Himan Chen

    您好，您能否告诉我如何将WebAPI添加到B2G，换句话说，我如何编写WebAPI？谢谢！！！

    2012年8月14日 19:59

    1. Robert Nyman

      WebAPIs是由Mozilla和社区开发，然后提交给W3C进行标准化。请加入该项目并分享您可能有的任何想法！

      2012年8月15日 01:14

本文的评论已关闭。