Use XMPP instead of HTTP

Question

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?

PS 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.

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?

Answer 1

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...

Answer 2

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).

Answer 3

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.

Answer 4

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.