历史

Protocol Buffers 创建背后的简要历史。

了解 protobuf 的创建原因以及随着时间推移而改变的决策,可以帮助您更好地使用该工具的功能。

为什么发布 Protocol Buffers?

我们发布 Protocol Buffers 有几个原因。

Protocol Buffers 被 Google 内部许多项目使用。我们还有其他项目希望作为开源项目发布,这些项目使用 Protocol Buffers,因此,为了做到这一点,我们需要首先发布 Protocol Buffers。事实上,该技术的一些部分已经进入了开源领域;如果您深入研究 Google AppEngine 的代码,可能会发现其中的一些内容。

我们希望提供接受 Protocol Buffers 以及 XML 的公共 API,因为这样做效率更高,而且无论如何我们都会将该 XML 转换为 Protocol Buffers。

我们认为 Google 之外的用户可能会发现 Protocol Buffers 有用。将 Protocol Buffers 转换为我们乐于发布的形式是一个有趣的副项目。

为什么第一个版本是 2?版本 1 发生了什么?

Protocol Buffers 的初始版本(“Proto1”)是从 2001 年初开始开发的,并在许多年里不断发展,只要有人需要新功能并且愿意付出努力创建它们,就会增加新功能。像任何以这种方式创建的东西一样,它有点一团糟。我们得出结论,以其当时的状态发布代码是不可行的。

版本 2(“Proto2”)是一个完整的重写,尽管它保留了大部分设计并使用了 Proto1 中的许多实现思想。添加了一些功能,删除了一些功能。最重要的是,代码得到了清理,并且没有任何依赖于尚未开源的 Google 库。

为什么叫“Protocol Buffers”?

这个名称起源于该格式的早期阶段,那时我们还没有协议缓冲区编译器来为我们生成类。当时,有一个名为 ProtocolBuffer 的类,它实际上充当单个方法的缓冲区。用户可以通过调用诸如 AddValue(tag, value) 之类的方法,分别向此缓冲区添加标签/值对。原始字节存储在缓冲区中,一旦消息构建完成,就可以将其写入。

从那时起,“缓冲区”部分的名称失去了其含义,但我们仍然使用它。如今,人们通常使用术语“协议消息”来指代抽象意义上的消息,“协议缓冲区”来指代消息的序列化副本,以及“协议消息对象”来指代表示已解析消息的内存中对象。

Google 是否持有 Protocol Buffers 的任何专利?

Google 目前没有关于 Protocol Buffers 的已颁发专利,我们很乐意解决人们可能对 Protocol Buffers 和专利提出的任何疑虑。

Protocol Buffers 与 ASN.1、COM、CORBA 和 Thrift 有什么区别?

我们认为所有这些系统都有优点和缺点。Google 在内部依赖于 Protocol Buffers,它们是我们成功的关键组成部分,但这并不意味着它们是每个问题的理想解决方案。您应该在您自己的项目背景下评估每个备选方案。

值得注意的是,这些技术中的几种技术都定义了交换格式和 RPC(远程过程调用)协议。Protocol Buffers 只是一个交换格式。它们可以很容易地用于 RPC——事实上,它们确实对定义 RPC 服务提供了有限的支持——但它们不与任何一个 RPC 实现或协议绑定。