3

这不是一个简单实用的问题，而是一个促进实时数据交换主题讨论的问题。

我将从一个例子开始：

Google Wave 的核心是实时异步数据同步引擎。Wave 支持（或计划支持）并发（实时）文档协作、断开连接（离线）文档编辑、冲突解决、文档历史记录和带归属地回放以及服务器联合。

Wave 的核心部分是 Operational Transformation 引擎：http ://www.waveprotocol.org/whitepapers/operational-transform

OT 引擎管理文档状态。客户端之间的更改被合并，并且每个客户端始终对文档有一个理智和一致的视图；最终文档在所有连接的客户端之间最终是一致的。

我的问题是：这个系统是否足够抽象或通用，可以用作库或通用框架来构建在每个客户端中同步实时、异步状态的 Web 应用程序？

Wave 协议是否被当前的任何 Web 应用程序（除了 Google 的客户端）直接使用？直接将它用于 Web 应用程序中的通用状态同步是否有意义？

在构建这样的 Web 应用程序时，您会考虑使用哪些其他现有库或框架？

这样的应用程序中有多少代码可能是特定于域的逻辑与通用状态同步逻辑？或者，换一种说法，状态同步抽象有多大的漏洞？

欢迎评论和讨论！

4

4 回答 4

1

Jack Moffitt 的书“ Professional XMPP Programming with JavaScript and jQuery ”提供了这个问题的答案，包括操作转换位。

于 2010-04-15T20:24:03.397 回答
1

就 OT 实施而言，Wave 确实被淡化了，并且没有——也不能——兑现您将在文献中读到的 OT 承诺。基于 Jupiter 协作系统，它仅限于客户端/服务器网络拓扑。谷歌进一步阻碍了 Jupiter OT 算法，以将给定客户端“飞行中”的操作数量限制为一个——这确实损害了客户端之间的交互性。

Wave有多“一般”？根据我对代码的回忆，它似乎与 Wave 数据模型紧密相关 - 光点、注释等。因此，我预计如果不进行认真修改，将很难将其应用于其他数据模型。

除此之外，我还会关注基于 Wave 的系统的可扩展性和稳健性。例如，只有一个服务器可以处理给定 Wave 上的操作，并且不清楚如何实现故障转移支持，因为服务器的任何回滚都几乎是灾难性的，导致所有客户端放弃他们的 Wave（包括未完成的操作） .

Wave 正在积极开发中，所以事情会随着时间的推移而改善。

Wave 的替代品并不多。正如我对这个问题的回答中所述，我使用 Ceda 进行基于 OT 的同步。Ceda 中没有“抽象泄漏”问题——它可以使用 OT 来同步任意数据结构——你的应用程序定义了模式。

于 2010-07-28T09:03:10.167 回答
0

您可以使用PubSubHubbub之类的东西来实现这一点，我认为这很简单。它的工作方式：两个系统都必须有代表数据的 RSS/Atom 提要，或者至少是数据上的事件“在 url XYZ 创建的对象”......等等。

然后，确保两个提要都启用了 PubSubHubbub，这意味着他们可以在订阅者更新其内容时通知他们。

为每个组件订阅其他组件的订阅源。

实现通知时发生的事情：下载文件，更新数据库中的内容......你可以命名它。

这样做的最大优点是它只依赖于“已知”的东西：HTTP、ATOM。

这篇博文给出了一个社交数据的例子，但这也适用于任何类型的数据。

于 2010-04-30T17:05:50.203 回答
0

HTTP 用于处理从客户端发起到服务器的调用，但这是您需要Push Technology的问题。我是一名网络开发人员，所以会使用Comet。

浏览器向服务器发出 Ajax 样式的请求，该请求保持打开状态，直到服务器有新数据要发送给浏览器，浏览器以完整响应的形式发送给浏览器。浏览器发起新的长轮询请求以获取后续事件。

您可以使用名为 Lift 的 Web 开发框架构建 Comet 风格的 Web 应用程序。（它是用一种叫做 Scala 的编程语言编写的，可以编译成 Java 字节码，这意味着你可以在 Java 应用服务器上运行它。）

值得关注的是 HTML5，它有一个称为Web Sockets的特性，它可能会使 Comet 过时。

于 2010-04-19T04:45:22.093 回答