我应该使用哪些库或平台来构建在客户端之间提供实时异步数据同步的 Web 应用程序？
这与其说是一个具有简单实用答案的问题，不如说是一个促进有关实时数据交换主题的讨论的问题。
我将从一个例子开始：
Google Wave 的核心是一个实时异步数据同步引擎。 Wave 支持（或计划支持）并发（实时）文档协作、断开连接（离线）文档编辑、冲突解决、文档历史记录和归因回放以及服务器联合。
Wave 的核心部分是操作转换引擎： http://www.waveprotocol.org/whitepapers /operational-transform
OT 引擎管理文档状态。客户之间的更改被合并，每个客户始终对文档拥有理智且一致的视图；最终文档最终在所有连接的客户端之间保持一致。
我的问题是：这个系统是否足够抽象或通用，可以用作库或通用框架来构建在每个客户端中同步实时、异步状态的 Web 应用程序？
Wave 协议是否被任何当前的 Web 应用程序直接使用（除了 Google 的客户端）？在 Web 应用程序中直接使用它进行通用状态同步是否有意义？
在构建此类 Web 应用程序时，您会考虑使用哪些其他现有库或框架？
这样的应用程序中有多少代码可能是特定于域的逻辑与通用状态同步逻辑？或者，换句话说，状态同步抽象的泄漏程度如何？
欢迎评论和讨论！
This is a less a question with a simple, practical answer and more a question to foster discussion on the real-time data exchange topic.
I'll begin with an example:
Google Wave is, at its core, a real-time asynchronous data synchronization engine. Wave supports (or plans to support) concurrent (real-time) document collaboration, disconnected (offline) document editing, conflict resolution, document history and playback with attribution, and server federation.
A core part of Wave is the Operational Transformation engine: http://www.waveprotocol.org/whitepapers/operational-transform
The OT engine manages document state. Changes between clients are merged and each client has a sane and consistent view of the document at all times; the final document is eventually consistent between all connected clients.
My question is: is this system abstract or general enough to be used as a library or generic framework upon which to build web apps that synchronize real-time, asynchronous state in each client?
Is the Wave protocol directly used by any current web applications (besides Google's client)? Would it make sense to directly use it for generic state synchronization in a web app?
What other existing libraries or frameworks would you consider using when building such a web app?
How much code in such an app might be domain-specific logic vs generic state synchronization logic? Or, put another way, how leaky might the state synchronization abstractions be?
Comments and discussion welcomed!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
Jack Moffitt 的书“使用 JavaScript 和 jQuery 进行专业 XMPP 编程”准确地提供了这个问题的答案，包括操作转换位。
Jack Moffitt's book "Professional XMPP Programming with JavaScript and jQuery" provides the answer to exactly this question, including the Operational Transform bits.
就 OT 实现而言，Wave 确实被淡化了，它没有——也不能——兑现您将在文献中读到的 OT 的承诺。由于基于 Jupiter 协作系统，它仅限于客户端/服务器网络拓扑。谷歌进一步限制了 Jupiter OT 算法，将给定客户端“飞行中”的操作数量限制为一个——这确实损害了客户端之间的交互性。
Wave有多“通用”？从我对代码的回忆来看，它似乎与 Wave 数据模型（blip、注释等）非常相关。因此，我预计如果不进行认真修改，很难将其应用到其他数据模型。
除此之外，我还担心基于 Wave 的系统的可扩展性和鲁棒性。例如，只有一台服务器可以处理给定 Wave 上的操作，并且不清楚如何实现故障转移支持，因为服务器的任何回滚都几乎是灾难性的，导致所有客户端放弃其 Wave（包括未完成的操作） 。
Wave 正在积极开发中，因此随着时间的推移，情况会有所改善。
Wave 的替代品并不多。正如我的对此问题的回答中所述，我使用 Ceda 进行基于 OT 的同步。 Ceda 中不存在“抽象泄漏”问题 - 它可以使用 OT 来同步任意数据结构 - 您的应用程序定义模式。
As far as OT implementations go, Wave is really watered down and does not - and can not - live up to the promise of OT that you will read about in the literature. Being based on the Jupiter collaborative system, it is limited to a client/server network topology. Google further hobbled the Jupiter OT algorithms to limit the number of operations "in flight" by a given client to one - this really hurts interactivity between clients.
How "general" is Wave? From what I recall of the code, it seems pretty tied to the Wave data model - blips, annotations, etc. So, I expect that it would be difficult to apply it to other data models without serious modification.
Beyond that, I would be concerned about scalability and robustness of a Wave based system. For example, only a single server can handle operations on a given Wave and it's not clear how you can implement fail over support since any rollback of the server at all is pretty much catastrophic, resulting in all clients ditching their waves (including outstanding operations).
Wave is actively under development, so things will improve over time.
There aren't many alternatives to Wave. As noted in my answer to this question, I use Ceda for OT based synchronisation. There is no "leaky abstraction" problem in Ceda - it can use OT to synchronise arbitrary data structures - your application defines the schema.
HTTP 是为了处理从客户端向服务器发起的调用，但这是一个问题，您需要 推送技术。我是一名网络开发人员，因此会使用 Comet。
您可以使用名为 Lift 的 Web 开发框架构建 Comet 风格的 Web 应用程序。 （它是用一种名为 Scala 的编程语言编写的，可编译为 Java 字节码，这意味着您可以在 Java 应用程序服务器上运行它。）
值得关注的是 HTML5，它有一个名为 Web Sockets 可能会使 Comet 过时。
HTTP was made to handle calls that were initiated from the client to the server, but this is a problem where you need Push Technology. I'm a web developer, so would use Comet.
You can build Comet-style Web applications using a web development framework called Lift. (It's written in a programming language called Scala that compiles down to Java bytecode, which means you can run it on a Java Application Server.)
Something interesting to watch for is HTML5, which has a feature called Web Sockets that may make Comet obsolete.
您可以使用 PubSubHubbub 之类的东西来实现这一点，我认为这非常简单。
它的工作方式：两个系统都必须有代表数据的 RSS/Atom 提要，或者至少是数据“在 url XYZ 创建的对象”上的事件...等等。
然后，确保两个提要都启用了 PubSubHubbub，这意味着他们可以在更新内容时通知订阅者。
将每个组件订阅其他组件的提要。
实现通知时发生的情况：下载文件、更新数据库中的内容......凡是你能想到的。
这样做的最大优点是它只依赖于“已知”的东西：HTTP、ATOM。
这篇博文给出了一个社交数据的示例，但是这也适用于任何类型的数据。
You can achieve this with something like PubSubHubbub and I think it's pretty simple.
The way it works : both systems have to have RSS/Atom feeds which represent the data, or at least events on the data "object at url XYZ created"... etc.
Then, make sure both feeds are PubSubHubbub enabled, which means that they can notify subscribers when they update their content.
Subscribe each component to the feeds of the other components.
Implement what happens on notification : downloading the file, updating stuff in a database... you name it.
The great advantage of this is that it relies only on stuff that are "known" : HTTP, ATOM.
This blog post gives an example with social data, but that can also apply to any type of data.