本文档将回答一些关于协议缓冲区开源项目的常见问题解答。如果您还有未在此解答的问题,请加入论坛进行提问!
常规
您为何释放协议缓冲区?
导致这种情况的原因有以下几种:
- Google 内部几乎所有人都使用协议缓冲区。我们还有许多其他项目要使用开放源代码进行发布,因此需要使用协议缓冲区,因此需要先发布协议缓冲区。事实上,一些技术已经在某种程度上开放了 - 如果您深入研究 Google AppEngine 的代码,可能会找到一些代码。
- 我们想提供接受协议缓冲区和 XML 的公共 API,因为这种方式更高效,而且我们只是要将 XML 转换为协议缓冲区。
- 我们认为 Google 之外的人可能会发现协议缓冲区很有用。
- 将协议缓冲区转换为我们很乐意发布的表单是一个有趣的 20% 项目。
为什么要发布第一个版本 2?版本 1 发生了什么变化?
协议缓冲区的初始版本(又称“Proto1”)从 2001 年初开始在 Google 开发,历经多年发展,在有人需要并且愿意自己动手推出时推出新功能。就像以这种方式制作的任何东西一样,有些混乱。我们发现,按原样发布代码并不可行。
版本 2(“Proto2”)是一个完全的重写,但它保留了大部分设计并使用了 Proto1 的许多实现想法。部分功能已添加,部分功能已移除。但最重要的是,相关代码会被清理,且对尚未开源的 Google 库没有任何依赖项。
为何使用“协议缓冲区”?
该名称源自这种格式的早期阶段,那时我们尚未使用协议缓冲区编译器来生成类。当时有一个名为 ProtocolBuffer
的类,它实际上充当单个方法的缓冲区。用户需要通过调用 AddValue(tag, value)
等方法,向此缓冲区中分别添加标记/值对。原始字节存储在缓冲区中,该缓冲区在构建消息后可以写出。
从那以后,名称的“buffers”部分已失去意义,但仍是我们使用的名称。如今,人们通常使用术语“协议消息”来引用抽象消息,使用“协议缓冲区”来指代消息的序列化副本,使用“协议消息对象”来指代表示已解析消息的内存对象。
Google 是否拥有协议缓冲区的专利?
Google 目前还没有关于协议缓冲区的专利,我们很乐意解决有关协议缓冲区和人们可能拥有的专利的任何问题。
类似技术
协议缓冲区与 XML 有何不同?
请参阅概览页面上的回答。
协议缓冲区与 ASN.1、COM、CORBA、Thrift 等有何区别?
我们认为所有这些系统都有各自的优缺点。Google 在内部依赖于协议缓冲区,它们对我们成功起着至关重要的作用,但这并不代表它们是解决所有问题的理想解决方案。您应该根据自己的项目来评估每种替代方案。
但需要注意的是,其中一些技术既定义了交换格式,又定义了 RPC(远程过程调用)协议。协议缓冲区只是一种交换格式。RPC 非常易于使用,并且确实对定义 RPC 服务的支持有限,但并不依赖于任何一种 RPC 实现或协议。
贡献
我可以向协议缓冲区添加对新语言的支持吗?
是的!事实上,协议缓冲区编译器的设计使得您可以轻松编写自己的编译器。请查看 CommandLineInterface
类,该类是 libprotoc
库的一部分。
我们建议您为新语言创建代码生成器和运行时库。为此,您应该启动自己的独立项目 - 这样,您就可以自由地管理项目,而不会被我们的发布流程阻止。请同时加入协议缓冲区论坛,向我们报告您的项目;我们很乐意链接到您的项目并帮助您解决设计问题。
我可以为协议缓冲区贡献补丁程序吗?
是的!请加入协议缓冲区论坛,与我们探讨相关事宜。
我可以向协议缓冲区添加新功能吗?
有可能需要。我们始终喜欢建议,但对于添加内容,我们非常谨慎。多年来我们了解到,有很多人对新功能很感兴趣。其中大多数功能在特定情况下非常有用,但如果我们接受了所有这些功能,协议缓冲区就会变得膨胀、混乱。所以我们必须非常挑剔在评估新功能时,我们会寻找广泛使用或极为简单的功能,或者希望两者兼而有之。我们会定期拒绝 Google 员工添加的功能。我们甚至定期拒绝我们自己的团队成员添加的功能。
不过,我们仍然希望了解您的想法。加入协议缓冲区论坛,告诉我们。我们或许可以帮您找到一种方法,在不更改底层库的情况下执行所需的操作。或者,我们可能认为您的地图项非常有用或太简单,应该添加。