使用 XMPP 代替 HTTP
我和我的朋友正在开发 iPhone 应用程序。该应用程序使用XMPP协议来提供聊天功能。现在我们正在为应用程序设计架构。
我的朋友正在 iPhone 方面工作，而我是 ruby on Rails 人员。
我的朋友建议，我们将通常通过 HTTP 提供的每个调用包装到 XMPP 中。因此，用户注册、用户搜索、个人资料编辑、照片上传，一切都通过 XMPP 进行。根本没有 HTTP。
我的朋友想要使用 XMPP，因为他说，在客户端实现 XMPP 比在 HTTP 上容易得多。对我来说，这是胡说八道，但我们有一个产品负责人，他和我的朋友一起工作了很长时间，他信任他。
因此，我想做的是让我的朋友和产品负责人相信，使用 XMPP 来实现 HTTP 可以找到的内容 — 完全不是最好的主意。
我觉得，如果我们把一切都实现在 XMPP 上，我们会一直痛苦到生命的尽头。但我该如何证明呢？
PS我并不反对通过XMPP聊天，我反对用户搜索、照片上传、排名、附近搜索和各种其他安全请求。
请留下回复。任何帮助表示赞赏。
一点更新：
昨天我们进行了长时间的讨论。事实证明，在 Objective-C 中接收来自 XMPP 和 HTTP 的响应非常困难。因为每个单独的对象及其数据都应该存储在 Core Data 模型中，而该模型不能从各个地方安全地修改。比如说，如果您使用 HTTP 传输，您总是希望仅使用 HTTP 传输来更新模型中的数据。如果您使用 XMPP，则应该始终使用 XMPP。所以，你不能同时使用两者。
这是我的 iPhone 好友告诉我的。 这对我来说听起来很奇怪，有人能给我解释一下吗？
My friend and I, we are working on iPhone application. This application uses XMPP protocol to provide chat functionality. Right now we are designing architecture for the application.
So my friend is working on iPhone side, and I am ruby on rails guy.
My friend suggested, that we wrap every call, that is usually served via HTTP into XMPP. So, user registration, users search, profile editing, photo uploading, everything goes via XMPP. No HTTP at all.
My friend wants to use XMPP, because he says, that it's much easier to implement XMPP on client-side rather HTTP. As for me, this is bullshit, but we've got a product owner, who have been working with my friend for a long time and he trusts him.
So what I'm trying to do is to convince my friend and product owner that using XMPP for what HTTP can work find — is totally not the best idea.
I feel, that if we implement everything on XMPP, we will have a pain in an ass till the end of lives. But how do I prove it?
P.S. I'm not against chat over XMPP, I am against users search, photo uploading, rankings, nearby search and various other restful requests.
Please, leave response. Any help appreciated.
A little update:
Yesterday we had a long discussion. And it turns out, it's quiete hard to receive response from both XMPP and HTTP in Objective-C. Because every single object and its data should be stored in Core Data model, while this model can't be securely modified from various places. Say, if you use HTTP transport, you always want to use only HTTP transport to update data in your model. And if you use XMPP, you should always use XMPP. So, you can't use both.
That's what my iPhone buddy told me.
It sounds weird for me, can anyone explain me that?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
这是与您更新的观点有关的答案，即无法从不同来源更新核心数据……
这对我来说根本不正确。我已经使用 HTTP、JSON 和 XML（XMPP 是其中的子集）完成了许多核心数据应用程序。以下正是使用核心数据的模式：
1) 从服务器获取数据
2) 使用所需的任何解析器进行解析（JSON、XML 等）。
3) 从解析后的字典或数组中获取数据，放入 Core Data 对象中。
4）保存核心数据模型。
对于 XMPP，您可能有一个流解析器，而不是在解析之前获取所有数据，但这并不重要。如果需要，有记录的方法可以使用不同的上下文将数据从后台线程存储到核心数据中。
基本上，该方法是将服务器请求分解为获取数据所需的任何操作，并且每个操作都可以将数据放入模型的不同部分。
也许他需要来自 HTTP 端的一些数据才能对 XMPP 数据进行操作？如果是这样，他可以只保存双方的部分数据，直到有足够的数据为止，并将该数据集标记为完整以供使用。
对于我来说，除了 XMPP 流量之外，将任何内容放入 XMPP 中都是有意义的……
This is an answer in relation to your updated points, about not being able to update Core Data from different sources...
That does not sound right to me, at all. I have done many Core Data applications with HTTP and JSON and XML (which XMPP is a subset of). Here's exactly how the pattern for working with Core Data goes:
1) Fetch data from server
2) Parse using whatever parser is required (JSON, XML, etc).
3) Take data from resulting parsed dictionary or array, place into Core Data object(s).
4) Save Core Data model.
In the case of XMPP, you might have a streaming parser instead of getting all the data before parsing, but that does not matter. There are documented ways of using different contexts to store data into Core Data from a background thread if that is required.
Basically the approach is to break you server requests into whatever operations you need to get data, and each one can put data into different parts of a model.
Perhaps he needs some data from the HTTP side before he can act on the XMPP data? If so he can just save partial data from both sides until he has enough, and flag that data set as complete to use.
There's just no scenario where it makes sense to me to put anything but XMPP traffic into XMPP...
指示他对所有 HTTP 调用使用 ASIHttpRequest，然后询问等效的库在哪里，该库将使 XMPP 调用中的数据包装变得同样简单...
XMPP 非常适合它的构建目的：聊天。 HTTP 非常适合它的用途——与 Web 服务器或 Web 服务进行通信。您将获得了解 POST 和 GET 之间差异的 Web 服务器，您将获得了解如何优化 HTTP 流量的代理，您将获得大负载的自动服务器端压缩，您将获得可在任何浏览器中分析的调用，您将获得无数的Charles 等工具旨在分析 HTTP 流量，以便您可以查看正在发送的内容。
当然，HTTP 在协议中内置了多种身份验证，由库为您处理，而不是在 XMPP 之上构建一个损坏的身份验证系统（并且您第一次设计任何身份验证系统时，它都会有缺陷）。
Point him to using ASIHttpRequest for all HTTP calls, and then ask where the equivalent library is that will make wrapping data in XMPP calls just as easy...
XMPP is great for what it was built for: chat. HTTP is great for what it does - communications with a web server, or web service. You get web servers that understand the difference between POST and GET, you get proxies that understand how to optimize HTTP traffic, you get automatic server side compression of large payloads, you get calls that you can analyze in any browser, you get a myriad of tools like Charles designed to analyse HTTP traffic so you can see what you are sending.
And of course HTTP has multiple kinds of authentication built into the protocol which the libraries handle for you, rather than building a broken authentication system on top of XMPP (and the first time you design any authentication system it WILL be flawed).
XMPP 比直接的 JSON 消息传递更难在 iPhone 上实现。插入一些 HTTP 调用并使用 JSON 响应来处理数据很容易。这是一个针对 iPhone 用户的快速教程。
如果您有一支经验丰富的团队可以处理，那么实施新的、伟大的事情是非常棒的。在你们两个能够很好地一起编程并跳出设备-服务器交互的框框之前，我会说坚持标准。
XMPP is harder to implement on an iPhone than straight JSON messeging. It is easy to throw in some HTTP calls and use a JSON repsonse to handle the data. Here is a quick tutorial for your iPhone guy.
Implementing new and great things is awesome, if you have an experienced team that can handle it. Until you two can program well together and think out of the box for device-server interaction, I would say stick with the standard.
XMPP 有一些优点：客户端易于实现、发布-订阅基础设施（在大多数情况下比 Http 轮询更好）、设计上的可伸缩性和可扩展性、开源社区等。
当然，HTTP 是比 XMPP 更成熟的协议/ 贾伯。使用 XMPP，您可能会遇到一些安全配置问题（端口阻塞等），而使用 HTTP 会更容易。
当涉及到实现功能和业务逻辑（排名、搜索...）时，在 XMPP 世界中，您必须创建一些非标准模块实现和/或对现有服务器代码库的修改。
您可以检查 XMPP over HTTP（通过 BOSH），以将 xmpp 与 http 协议结合使用，使用到 http 服务器的双向流。
最近推出了一些在 XMPP 协议上运行的 Web 应用程序：chesspark（已关闭）、drop.io。
请注意：大多数 XMPP 服务器支持现代身份验证机制和加密类型 (TLS)。
XMPP 是成熟的、有据可查且功能强大的协议，适用于许多事情，但您必须非常小心地选择它作为项目的主要开发环境。你必须花一些时间来检查它是否真的适合你的需求。我推荐 O'Reilly 的 XMPP Book 作为参考。
There are some certain advantages of XMPP : easy implementation on the client side, publish-subscribe infrastructure (better than Http polling in most cases), scalable and extensible by design , open source community etc.
Of course , HTTP is more mature protocol than XMPP / Jabber. With XMPP you might have some problems with security configurations (port blockings etc), HTTP would much more easy to go with.
When it comes to implementing functionality and business logic (ranking, search ...) , in XMPP world, you have to create some unstandard module implementations and/or modifications of existing server's code bases.
You can check XMPP over HTTP (via BOSH) to use xmpp with http protocol using bidirectional streams to http servers.
In recent there were some web applications launched runs on XMPP protocol : chesspark (closed) , drop.io.
As a note : most of XMPP servers supports modern authentication mechanisms and encryption types (TLS).
XMPP is mature, well documented and quite capable protocol for many things but you have to be very careful to choose it as a main development environment for your project. You have to spend some time to check if it really fits for your needs. I recommend XMPP Book from O'Reilly as a reference.