我目前正在根据此页面上提供的规范实施 DDP 客户端： https://github.com/meteor/meteor/blob/master/packages/livedata/DDP.md
我只是对“就绪”和“更新”这两种方法类型存有疑问。
根据规范，让我们从“准备就绪”开始：
当一个或多个订阅完成发送他们的初始 批量数据，服务器将发送一条带有它们的 ID 的就绪消息。
这样做意味着我们可以从服务器获得多个“添加”消息，直到将整个集合完全传输到客户端。我们应该把它存储在一个临时的地方，然后等待“准备好的”信号量在公开之前？即在真正的收藏中？
关于远程过程调用的相同问题。我是否应该将结果存储在临时集合中，并且仅在收到“更新”消息后才返回（处理）结果？
这部分很晦涩
一旦服务器根据这个过程调用完成向客户端发送所有相关的数据消息，服务器应该发送一个 使用此方法的 ID 向客户端更新消息。
“应该”，所以如果我确实依赖它但什么都没有，我会被卡住吗？
【问题讨论】：
我们应该把它存放在一个临时的地方，然后等待“准备好” 信号量在公开之前？即在真正的收藏中？
标准 Meteor JavaScript 客户端使添加的文档在客户端集合中可用，因为它们来自服务器。因此，例如，如果集合正在网页上显示，并且到目前为止 100 个文档中有 5 个已到达，则用户将能够看到这 5 个文档。
当订阅“就绪”消息到达时，客户端上的订阅被标记为“就绪”，如果客户端正在执行需要等待所有数据到达的操作，则可以使用该消息。
您是否要在客户中等待所有数据到达后再将其公开取决于您...这取决于您对客户所做的事情以及您是否希望在文件到达时显示它们或不是。
“应该”，所以如果我确实依赖它但什么都没有，我会被卡住吗？
Meteor 服务器确实发送“更新”消息，因此您可以依赖它。
关于远程过程调用的相同问题。我是否应该将结果存储在临时集合中，并且仅在收到“更新”消息后才返回（处理）结果？
进行方法调用有两种结果：方法返回的返回值（或错误）（“结果”消息），以及方法调用可能已插入/更新/删除的文档（“更新”消息）。您想听哪一个取决于您：您是否需要知道何时收到来自方法调用的所有文档更改，或者您是否只需要方法返回值。
Meteor 客户端使用“更新”消息来执行“延迟补偿”：当客户端更改本地文档时，更改会立即应用于本地文档（并且更改将对用户可见）。 ..假设更改可能会被服务器接受。然后客户端发出一个请求更改的方法调用，并等待从服务器发送更新的文档（如果它们被接受，则可能包括更改，如果被拒绝，则可能包括更改）。当接收到“更新”消息时，本地更改被丢弃并被来自服务器的真实更新所取代。如果您没有在自己的客户端中进行延迟补偿，那么您可能不会关心“更新”消息。
【讨论】：